HoRain 云小助手个人主页⛺️生活的理想就是为了理想的生活!⛳️ 推荐前些天发现了一个超棒的服务器购买网站性价比超高大内存超划算忍不住分享一下给大家。点击跳转到网站。目录⛳️ 推荐服务器Docker OOM与RSS高问题排查思路1. 快速诊断与应急处理1.1 立即查看容器状态1.2 查看容器资源限制2. 深入诊断工具集2.1 Docker原生工具2.2 宿主机工具2.3 容器内诊断3. RSS高的原因分析3.1 理解内存类型3.2 常见RSS高的原因4. 应用层深度排查4.1 Java应用排查4.2 Node.js应用排查4.3 Python应用排查4.4 Go应用排查5. Docker配置优化5.1 内存限制配置5.2 运行时参数6. 监控与告警6.1 Prometheus监控配置6.2 Grafana监控面板7. 问题解决策略7.1 临时缓解措施7.2 长期解决方案8. 高级排查工具8.1 使用perf分析8.2 使用ebpf工具8.3 使用systemtap9. 预防措施检查清单✅ 配置检查✅ 应用检查✅ 监控告警✅ 运维流程总结排查步骤服务器Docker OOM与RSS高问题排查思路1. 快速诊断与应急处理1.1 立即查看容器状态# 查看运行中容器的内存使用情况 docker stats --no-stream # 查看已停止的容器特别是OOM退出的 docker ps -a | grep -E (Exited|OOM) # 查看容器详细状态 docker inspect container_id --format{{json .State}} # 查看系统OOM日志 dmesg | grep -i oom dmesg | grep -i kill journalctl -k | grep -i oom1.2 查看容器资源限制# 查看容器的内存限制 docker inspect container_id --format{{.HostConfig.Memory}} {{.HostConfig.MemorySwap}} # 查看cgroup内存配置 cat /sys/fs/cgroup/memory/docker/container_id/memory.limit_in_bytes cat /sys/fs/cgroup/memory/docker/container_id/memory.usage_in_bytes cat /sys/fs/cgroup/memory/docker/container_id/memory.stat2. 深入诊断工具集2.1 Docker原生工具# 实时监控容器资源 docker stats --format table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.NetIO}}\t{{.BlockIO}} # 查看容器详细资源使用 docker container stats container_id --no-stream # 导出容器性能指标 docker stats --no-stream --format json container_stats.json2.2 宿主机工具# 查看系统整体内存 free -h cat /proc/meminfo # 按进程查看内存使用 top -o %MEM htop ps aux --sort-rss | head -20 # 使用smem查看更准确的内存统计 smem -t -k -p smem -P process_name -t -k2.3 容器内诊断# 进入容器 docker exec -it container_id /bin/bash # 查看容器内进程 ps aux --sort-rss # 查看容器内内存信息 cat /proc/meminfo free -h # 查看特定进程的内存映射 pmap -x pid | tail -1 cat /proc/pid/smaps3. RSS高的原因分析3.1 理解内存类型# 查看容器内存详细统计 cat /sys/fs/cgroup/memory/docker/container_id/memory.stat # 关键指标解释 # rss - Resident Set Size (常驻内存) # cache - 页面缓存 # swap - 交换内存 # mapped_file - 内存映射文件 # total_rss - 总RSS包括匿名和文件映射3.2 常见RSS高的原因1. 内存泄漏 - 应用程序内存管理问题 - 库/框架的内存泄漏 - 未释放的资源 2. 配置不当 - 堆大小设置过大 - 缓存配置过大 - 连接池配置过大 3. 工作负载 - 数据处理时加载大量数据到内存 - 缓存了大量数据 - 并发连接数过高 4. 系统/内核问题 - 内存碎片 - slab内存泄漏 - 内核bug4. 应用层深度排查4.1 Java应用排查# 进入容器查看Java进程 docker exec container_id jps -l # 查看GC情况 docker exec container_id jstat -gc pid 1000 5 docker exec container_id jstat -gccapacity pid # 生成堆转储谨慎使用会产生大文件 docker exec container_id jmap -dump:live,formatb,file/tmp/heap.hprof pid # 查看堆内存分布 docker exec container_id jmap -heap pid docker exec container_id jcmd pid GC.heap_info4.2 Node.js应用排查# 生成堆快照 docker exec container_id node --heapsnapshot-signalSIGUSR2 pid # 使用v8-profiler # 在应用代码中添加 # const profiler require(v8-profiler-node8); # const snapshot profiler.takeSnapshot(); # 查看内存使用 docker exec container_id node -e console.log(process.memoryUsage())4.3 Python应用排查# 使用objgraph docker exec container_id pip install objgraph # 在代码中添加 # import objgraph # objgraph.show_most_common_types(limit20) # 使用tracemalloc # 在代码开始处添加 # import tracemalloc # tracemalloc.start() # ... 在需要时 # snapshot tracemalloc.take_snapshot() # top_stats snapshot.statistics(lineno) # 使用memory_profiler # profile # def your_function(): # ...4.4 Go应用排查# 生成内存profile # 在代码中添加 # import _ net/http/pprof # 访问 http://localhost:6060/debug/pprof/heap?debug1 # 或通过信号生成 kill -USR1 pid # 生成goroutine dump curl http://localhost:6060/debug/pprof/heap heap.out go tool pprof heap.out5. Docker配置优化5.1 内存限制配置# docker-compose.yml version: 3.8 services: your-app: deploy: resources: limits: memory: 1G cpus: 0.5 reservations: memory: 512M cpus: 0.25 mem_limit: 1g memswap_limit: 2g mem_reservation: 512m oom_kill_disable: false oom_score_adj: 5005.2 运行时参数# 运行容器时设置内存限制 docker run -d \ --name myapp \ --memory1g \ # 硬限制 --memory-reservation512m \ # 软限制 --memory-swap2g \ # 交换内存 --memory-swappiness10 \ # 交换倾向性(0-100) --oom-kill-disablefalse \ # 不禁用OOM Killer --oom-score-adj500 \ # OOM优先级调整 your-image:latest6. 监控与告警6.1 Prometheus监控配置# prometheus.yml scrape_configs: - job_name: docker static_configs: - targets: [docker-host:9323] # cAdvisor暴露指标 docker run \ --volume/:/rootfs:ro \ --volume/var/run:/var/run:ro \ --volume/sys:/sys:ro \ --volume/var/lib/docker/:/var/lib/docker:ro \ --publish8080:8080 \ --detachtrue \ --namecadvisor \ google/cadvisor:latest6.2 Grafana监控面板-- 关键监控指标查询 -- 容器内存使用率 sum(container_memory_working_set_bytes{name!}) by (name) / sum(container_spec_memory_limit_bytes{name!}) by (name) * 100 -- 容器RSS sum(container_memory_rss{name!}) by (name) -- OOM事件计数 count(container_oom_events_total) -- 内存压力 rate(container_memory_failures_total[5m])7. 问题解决策略7.1 临时缓解措施# 1. 重启有问题的容器 docker restart container_id # 2. 调整内存限制 docker update --memory 2g --memory-swap 3g container_id # 3. 清理缓存 echo 1 /proc/sys/vm/drop_caches # 或在容器内 sync echo 3 /proc/sys/vm/drop_caches # 4. 限制进程数 docker update --pids-limit 100 container_id7.2 长期解决方案# 1. 应用内存优化 - 实现内存使用监控和告警 - 添加内存使用统计日志 - 实现优雅降级机制 # 2. Docker配置优化 - 设置合理的memory和memory-swap - 启用memory reservation - 合理设置oom_score_adj # 3. 部署策略 - 实现滚动更新避免全量重启 - 设置健康检查自动恢复 - 实现pod水平自动扩展(HPA) # 4. 监控告警 - 设置内存使用率阈值告警(如85%) - 监控OOM事件 - 实现自动扩容机制8. 高级排查工具8.1 使用perf分析# 在宿主机上分析容器进程 # 找到容器在宿主机上的PID docker inspect container_id --format {{.State.Pid}} # 使用perf记录 perf record -F 99 -p host_pid -g -- sleep 30 perf report # 使用perf mem记录内存分配 perf mem record -p host_pid -- sleep 10 perf mem report8.2 使用ebpf工具# 使用bcc工具集 # 安装bcc apt-get install bpfcc-tools # 查看内存分配 memleak-bpfcc -p pid # 跟踪内存分配调用栈 stackcount-bpfcc -p pid kmem:kmalloc # 查看页面错误 funccount-bpfcc -p pid t:exceptions:page_fault_user8.3 使用systemtap# 安装systemtap yum install systemtap kernel-devel # 监控内存分配 stap -e probe kernel.function(kmalloc) { printf(kmalloc size: %d\n, $size); }9. 预防措施检查清单✅ 配置检查[ ] 设置合理的容器内存限制[ ] 配置memory swap适当[ ] 设置memory reservation[ ] 禁用不必要的OOM Killer保护[ ] 设置合理的OOM优先级✅ 应用检查[ ] 实现内存使用监控[ ] 添加内存泄漏检测[ ] 实现优雅的内存清理[ ] 配置合理的缓存策略[ ] 优化数据结构内存使用✅ 监控告警[ ] 设置内存使用率告警[ ] 监控OOM事件[ ] 实现自动扩容策略[ ] 定期检查内存趋势[ ] 设置日志轮转防止日志占满磁盘✅ 运维流程[ ] 压力测试内存使用[ ] 定期进行内存泄漏检查[ ] 制定OOM应急响应流程[ ] 建立性能基线[ ] 文档化内存优化实践总结排查步骤立即响应查看容器状态、日志确认OOM事件定位问题容器通过docker stats、cgroup信息定位深入容器内部分析进程内存使用区分RSS、Cache、Swap应用层分析根据应用类型使用相应工具分析内存分配根源分析确定是配置问题、内存泄漏还是工作负载问题实施解决方案调整配置、修复代码、优化架构建立预防措施监控、告警、自动化、文档化通过系统性的排查可以解决绝大多数Docker OOM和RSS高的问题。关键在于快速定位问题容器深入分析内存使用模式然后针对性地优化配置或修复代码。❤️❤️❤️本人水平有限如有纰漏欢迎各位大佬评论批评指正如果觉得这篇文对你有帮助的话也请给个点赞、收藏下吧非常感谢! Stay Hungry Stay Foolish 道阻且长,行则将至,让我们一起加油吧
HoRain云--Docker内存泄漏排查全攻略
HoRain 云小助手个人主页⛺️生活的理想就是为了理想的生活!⛳️ 推荐前些天发现了一个超棒的服务器购买网站性价比超高大内存超划算忍不住分享一下给大家。点击跳转到网站。目录⛳️ 推荐服务器Docker OOM与RSS高问题排查思路1. 快速诊断与应急处理1.1 立即查看容器状态1.2 查看容器资源限制2. 深入诊断工具集2.1 Docker原生工具2.2 宿主机工具2.3 容器内诊断3. RSS高的原因分析3.1 理解内存类型3.2 常见RSS高的原因4. 应用层深度排查4.1 Java应用排查4.2 Node.js应用排查4.3 Python应用排查4.4 Go应用排查5. Docker配置优化5.1 内存限制配置5.2 运行时参数6. 监控与告警6.1 Prometheus监控配置6.2 Grafana监控面板7. 问题解决策略7.1 临时缓解措施7.2 长期解决方案8. 高级排查工具8.1 使用perf分析8.2 使用ebpf工具8.3 使用systemtap9. 预防措施检查清单✅ 配置检查✅ 应用检查✅ 监控告警✅ 运维流程总结排查步骤服务器Docker OOM与RSS高问题排查思路1. 快速诊断与应急处理1.1 立即查看容器状态# 查看运行中容器的内存使用情况 docker stats --no-stream # 查看已停止的容器特别是OOM退出的 docker ps -a | grep -E (Exited|OOM) # 查看容器详细状态 docker inspect container_id --format{{json .State}} # 查看系统OOM日志 dmesg | grep -i oom dmesg | grep -i kill journalctl -k | grep -i oom1.2 查看容器资源限制# 查看容器的内存限制 docker inspect container_id --format{{.HostConfig.Memory}} {{.HostConfig.MemorySwap}} # 查看cgroup内存配置 cat /sys/fs/cgroup/memory/docker/container_id/memory.limit_in_bytes cat /sys/fs/cgroup/memory/docker/container_id/memory.usage_in_bytes cat /sys/fs/cgroup/memory/docker/container_id/memory.stat2. 深入诊断工具集2.1 Docker原生工具# 实时监控容器资源 docker stats --format table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.NetIO}}\t{{.BlockIO}} # 查看容器详细资源使用 docker container stats container_id --no-stream # 导出容器性能指标 docker stats --no-stream --format json container_stats.json2.2 宿主机工具# 查看系统整体内存 free -h cat /proc/meminfo # 按进程查看内存使用 top -o %MEM htop ps aux --sort-rss | head -20 # 使用smem查看更准确的内存统计 smem -t -k -p smem -P process_name -t -k2.3 容器内诊断# 进入容器 docker exec -it container_id /bin/bash # 查看容器内进程 ps aux --sort-rss # 查看容器内内存信息 cat /proc/meminfo free -h # 查看特定进程的内存映射 pmap -x pid | tail -1 cat /proc/pid/smaps3. RSS高的原因分析3.1 理解内存类型# 查看容器内存详细统计 cat /sys/fs/cgroup/memory/docker/container_id/memory.stat # 关键指标解释 # rss - Resident Set Size (常驻内存) # cache - 页面缓存 # swap - 交换内存 # mapped_file - 内存映射文件 # total_rss - 总RSS包括匿名和文件映射3.2 常见RSS高的原因1. 内存泄漏 - 应用程序内存管理问题 - 库/框架的内存泄漏 - 未释放的资源 2. 配置不当 - 堆大小设置过大 - 缓存配置过大 - 连接池配置过大 3. 工作负载 - 数据处理时加载大量数据到内存 - 缓存了大量数据 - 并发连接数过高 4. 系统/内核问题 - 内存碎片 - slab内存泄漏 - 内核bug4. 应用层深度排查4.1 Java应用排查# 进入容器查看Java进程 docker exec container_id jps -l # 查看GC情况 docker exec container_id jstat -gc pid 1000 5 docker exec container_id jstat -gccapacity pid # 生成堆转储谨慎使用会产生大文件 docker exec container_id jmap -dump:live,formatb,file/tmp/heap.hprof pid # 查看堆内存分布 docker exec container_id jmap -heap pid docker exec container_id jcmd pid GC.heap_info4.2 Node.js应用排查# 生成堆快照 docker exec container_id node --heapsnapshot-signalSIGUSR2 pid # 使用v8-profiler # 在应用代码中添加 # const profiler require(v8-profiler-node8); # const snapshot profiler.takeSnapshot(); # 查看内存使用 docker exec container_id node -e console.log(process.memoryUsage())4.3 Python应用排查# 使用objgraph docker exec container_id pip install objgraph # 在代码中添加 # import objgraph # objgraph.show_most_common_types(limit20) # 使用tracemalloc # 在代码开始处添加 # import tracemalloc # tracemalloc.start() # ... 在需要时 # snapshot tracemalloc.take_snapshot() # top_stats snapshot.statistics(lineno) # 使用memory_profiler # profile # def your_function(): # ...4.4 Go应用排查# 生成内存profile # 在代码中添加 # import _ net/http/pprof # 访问 http://localhost:6060/debug/pprof/heap?debug1 # 或通过信号生成 kill -USR1 pid # 生成goroutine dump curl http://localhost:6060/debug/pprof/heap heap.out go tool pprof heap.out5. Docker配置优化5.1 内存限制配置# docker-compose.yml version: 3.8 services: your-app: deploy: resources: limits: memory: 1G cpus: 0.5 reservations: memory: 512M cpus: 0.25 mem_limit: 1g memswap_limit: 2g mem_reservation: 512m oom_kill_disable: false oom_score_adj: 5005.2 运行时参数# 运行容器时设置内存限制 docker run -d \ --name myapp \ --memory1g \ # 硬限制 --memory-reservation512m \ # 软限制 --memory-swap2g \ # 交换内存 --memory-swappiness10 \ # 交换倾向性(0-100) --oom-kill-disablefalse \ # 不禁用OOM Killer --oom-score-adj500 \ # OOM优先级调整 your-image:latest6. 监控与告警6.1 Prometheus监控配置# prometheus.yml scrape_configs: - job_name: docker static_configs: - targets: [docker-host:9323] # cAdvisor暴露指标 docker run \ --volume/:/rootfs:ro \ --volume/var/run:/var/run:ro \ --volume/sys:/sys:ro \ --volume/var/lib/docker/:/var/lib/docker:ro \ --publish8080:8080 \ --detachtrue \ --namecadvisor \ google/cadvisor:latest6.2 Grafana监控面板-- 关键监控指标查询 -- 容器内存使用率 sum(container_memory_working_set_bytes{name!}) by (name) / sum(container_spec_memory_limit_bytes{name!}) by (name) * 100 -- 容器RSS sum(container_memory_rss{name!}) by (name) -- OOM事件计数 count(container_oom_events_total) -- 内存压力 rate(container_memory_failures_total[5m])7. 问题解决策略7.1 临时缓解措施# 1. 重启有问题的容器 docker restart container_id # 2. 调整内存限制 docker update --memory 2g --memory-swap 3g container_id # 3. 清理缓存 echo 1 /proc/sys/vm/drop_caches # 或在容器内 sync echo 3 /proc/sys/vm/drop_caches # 4. 限制进程数 docker update --pids-limit 100 container_id7.2 长期解决方案# 1. 应用内存优化 - 实现内存使用监控和告警 - 添加内存使用统计日志 - 实现优雅降级机制 # 2. Docker配置优化 - 设置合理的memory和memory-swap - 启用memory reservation - 合理设置oom_score_adj # 3. 部署策略 - 实现滚动更新避免全量重启 - 设置健康检查自动恢复 - 实现pod水平自动扩展(HPA) # 4. 监控告警 - 设置内存使用率阈值告警(如85%) - 监控OOM事件 - 实现自动扩容机制8. 高级排查工具8.1 使用perf分析# 在宿主机上分析容器进程 # 找到容器在宿主机上的PID docker inspect container_id --format {{.State.Pid}} # 使用perf记录 perf record -F 99 -p host_pid -g -- sleep 30 perf report # 使用perf mem记录内存分配 perf mem record -p host_pid -- sleep 10 perf mem report8.2 使用ebpf工具# 使用bcc工具集 # 安装bcc apt-get install bpfcc-tools # 查看内存分配 memleak-bpfcc -p pid # 跟踪内存分配调用栈 stackcount-bpfcc -p pid kmem:kmalloc # 查看页面错误 funccount-bpfcc -p pid t:exceptions:page_fault_user8.3 使用systemtap# 安装systemtap yum install systemtap kernel-devel # 监控内存分配 stap -e probe kernel.function(kmalloc) { printf(kmalloc size: %d\n, $size); }9. 预防措施检查清单✅ 配置检查[ ] 设置合理的容器内存限制[ ] 配置memory swap适当[ ] 设置memory reservation[ ] 禁用不必要的OOM Killer保护[ ] 设置合理的OOM优先级✅ 应用检查[ ] 实现内存使用监控[ ] 添加内存泄漏检测[ ] 实现优雅的内存清理[ ] 配置合理的缓存策略[ ] 优化数据结构内存使用✅ 监控告警[ ] 设置内存使用率告警[ ] 监控OOM事件[ ] 实现自动扩容策略[ ] 定期检查内存趋势[ ] 设置日志轮转防止日志占满磁盘✅ 运维流程[ ] 压力测试内存使用[ ] 定期进行内存泄漏检查[ ] 制定OOM应急响应流程[ ] 建立性能基线[ ] 文档化内存优化实践总结排查步骤立即响应查看容器状态、日志确认OOM事件定位问题容器通过docker stats、cgroup信息定位深入容器内部分析进程内存使用区分RSS、Cache、Swap应用层分析根据应用类型使用相应工具分析内存分配根源分析确定是配置问题、内存泄漏还是工作负载问题实施解决方案调整配置、修复代码、优化架构建立预防措施监控、告警、自动化、文档化通过系统性的排查可以解决绝大多数Docker OOM和RSS高的问题。关键在于快速定位问题容器深入分析内存使用模式然后针对性地优化配置或修复代码。❤️❤️❤️本人水平有限如有纰漏欢迎各位大佬评论批评指正如果觉得这篇文对你有帮助的话也请给个点赞、收藏下吧非常感谢! Stay Hungry Stay Foolish 道阻且长,行则将至,让我们一起加油吧
