Linux 内存泄漏排查方法总结

判断内存泄漏需关注vmrss持续上涨、free -h可用内存减少及swap启用，而非仅看top的%mem；结合gdb堆分析、py-spy火焰图定位c层泄漏，并配置systemd内存限制与监控。

怎么看进程是不是在吃内存不放

直接看 /proc/[pid]/status 里的 VmRSS 和 VmSize，前者是实际物理内存占用，后者是虚拟地址空间大小。如果程序逻辑没变但 VmRSS 持续缓慢上涨，且 free -h 显示可用内存不断减少、swap 开始被用上，基本就是泄漏了。

别只盯 top 的 %MEM —— 它按比例算，小进程涨几百 KB 看不出；也别信 ps aux --sort=-rss 一眼扫完就下结论，得持续观察趋势。

• 用 watch -n 1 'cat /proc/1234/status | grep -E "VmRSS|VmSize"' 替代肉眼刷新
• 注意区分“缓存增长”和“泄漏”：Slab 或 PageCache 上涨可能是内核行为，查 /proc/meminfo 里 Slab、Cached 字段变化
• 如果进程 fork 频繁（比如 CGI 模式），VmRSS 累加可能掩盖单次泄漏，优先抓子进程生命周期内的内存快照

gdb 调试运行中 C/C++ 进程的堆分配点

不是所有泄漏都能靠 valgrind 复现——生产环境不开调试符号、不能停服务、valgrind 本身慢 10 倍以上。这时候用 gdb 附加后查堆状态更实际。

前提是进程用了 glibc 默认 malloc，且没被 LD_PRELOAD 替换过分配器。先确认：cat /proc/[pid]/maps | grep libc.so 有输出，再进 gdb -p [pid]。

• 执行 call malloc_stats() 打印当前堆统计（会输出到进程 stderr，确保它没被重定向丢弃）
• 用 info proc mappings 找 heap 段地址，再 dump memory heap.bin [start] [end] 抓原始堆数据，后续用 strings heap.bin | grep -E "your_struct_name|malloc" 辅助定位
• 容易漏：gdb 里 malloc 符号默认不加载，需先 set environment MALLOC_CHECK_=1 再 call malloc_stats()，否则可能返回空或报错 Cannot find bounds of current function

Python 进程 RSS 涨但 gc.get_objects() 数量不变怎么办

说明泄漏不在 Python 对象层，大概率在 C 扩展里（比如 numpy 数组没释放底层 buffer、ctypes 加载的 so 模块调用 malloc 后没 free、PIL 图片解码后内存没归还）。

先排除常见陷阱：gc.disable() 没开、循环引用已清理、__del__ 没卡住对象——这些都检查完还涨，就得切到 C 层。

• 用 py-spy record -p [pid] --duration 60 生成火焰图，重点看 libpython 外部的调用栈（比如 libjpeg.so、libz.so）
• 检查是否用了 mmap：Python 的 mmap.mmap 不触发 GC，del 后仍占 VmRSS，必须显式调用 .close()
• objgraph.show_growth() 只能看 Python 对象，对 numpy.ndarray 底层内存无效；要查它，得用 np.sum([arr.nbytes for arr in gc.get_objects() if isinstance(arr, np.ndarray)]) 算总字节数趋势

systemd 服务内存泄漏后自动重启的坑

加 Restart=on-failure 或 RestartSec=5 看似能兜底，但可能掩盖问题、放大影响：泄漏进程在重启前已把 OOM Killer 招来，顺手干掉其他重要服务；或者泄漏发生在初始化阶段，每次重启都重复加载大资源，加速系统崩溃。

更糟的是，systemd 默认不清除 cgroup 内存统计，MemoryCurrent 在重启后继续累加，导致 MemoryMax 限流失效。

• 务必配 MemoryAccounting=true + MemoryMax=512M（按需调），并监控 systemctl show -p MemoryCurrent [service]
• 重启前加钩子：ExecStopPre=/bin/sh -c 'echo $(date): RSS=$(cat /proc/$(cat /run/systemd/journal/stdout) | grep VmRSS | awk "{print $2}")" >> /var/log/myapp-rss.log'，留痕比猜有用
• 不要依赖 OOMScoreAdjust=-1000 来保命——它只是降低被 kill 概率，不解决泄漏；真到了 OOM 阶段，kernel 日志里 Out of memory: Kill process 已经是最后一道防线了

内存泄漏最麻烦的不是找不到，是它常藏在你认为“不可能出问题”的路径里：一个日志模块的缓冲区没 flush、一次失败的 socket connect 留下的未 cleanup 的 SSL_CTX、甚至 strftime 在多线程下静态缓存导致的隐式增长。查的时候，少想“应该在哪”，多看“现在在哪”。