判断内存泄漏需关注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 在多线程下静态缓存导致的隐式增长。查的时候，少想“应该在哪”，多看“现在在哪”。
