Linux内存持续上涨未必是泄漏，但若available单边下降且不随负载回落，需排查；重点看RssAnon、heap、MMAP_AREA是否单调增长，结合slabtop、valgrind等工具定位根因。

Linux内存持续上涨不等于一定发生了内存泄漏，但若上涨不可逆、不随负载下降而回落，就该严肃排查。真正要盯的不是“用了多少”，而是“谁占着不放、为什么放不掉”。

先看系统级表征：free 和 vmstat 快速筛异常

运行 watch -n 5 'free -h'，重点观察两列：

• available：持续单边下降，且不随业务低谷回升 → 内存被“钉住”，回收机制失效；
• buff/cache：同步上涨是正常缓存行为；但若它涨得猛、available 却跌得更快，尤其 SReclaimable（可回收 slab）不增，Slab 或 SUnreclaim 却持续走高 → 很可能是内核态泄漏（如 dentry、inode、skbuff 等对象未释放）。

再跑 vmstat 1，关注：

• sr（或 re）> 0 且稳定存在：kswapd 持续扫描 LRU 链表，说明物理页压力大；
• si/so 非零：已开始 swap，是内存严重不足的强信号；
• in（中断）或 cs（上下文切换）突增 + available 下跌：可能指向高频内核分配路径，比如网络收包、定时器回调反复 kmalloc。

定位用户进程：别信 top 的 RES，盯死 /proc/[pid]/smaps

top 或 ps 显示的 RES 包含共享内存、mmap 文件页、匿名页等，初期泄漏时变化迟钝。真实泄漏信号藏在：

Linux Ai Server

Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。

下载

• RssAnon：堆外匿名页（如 mmap(MAP_ANONYMOUS)、libcurl/openssl 的内部缓冲区）；
• heap：malloc/sbrk 分配的堆内存；
• MMAP_AREA（如 libcurl 常用区域）：容易被忽略，但泄漏频发。

快速抓取示例：
awk '/^RssAnon:|heap:|^MMAP_AREA/ {print}' /proc/1234/smaps
建议用循环每 5 秒采样一次，观察是否单调增长。若 RES 突增但 RssAnon 不变，大概率是 page cache 或共享内存，不是泄漏。

进程内部分析：线上不能停？用 gdb 实时看堆状态

对无法重启的服务，gdb 是最轻量的实时诊断工具：

• gdb -p [pid] 进入后执行 call malloc_stats()：看 “total allocated” 是否持续上涨，“fastbins/unsorted bins” 是否长期积压；
• 若 “max system bytes” 增速明显快于 “total allocated”，说明 malloc 正不断向内核申请新页，泄漏已较严重；
• 加载 gef 或 pwndbg 后可用 heap 命令列出所有 in-use chunk，重点关注 size 大、无变量名、生命周期异常长的小块（如 32/64 字节），可能是对象池未回收或 SSO 失效。

注意：gdb 会暂停进程，务必选低峰期操作；更稳妥方式是先 gcore [pid] 打快照，再离线分析。

根因确认与修复：valgrind + 内核工具组合验证

开发环境或测试机上，用 valgrind 定位 C/C++ 堆泄漏：

• 必须关闭 ASLR：echo 0 | sudo tee /proc/sys/kernel/randomize_va_space，否则调用栈全是 ??:?；
• 编译时禁用优化：gcc -O0，避免行号错位；
• 基础命令：valgrind --leak-check=full --track-origins=yes ./a.out；
• 多线程程序加 --tool=helgrind 查竞态导致的间接泄漏。

内核泄漏则靠：

• slabtop -o（按活跃度排序），查哪个 kmem_cache 对象数暴涨；
• cat /proc/slabinfo | grep -E "(dentry|inode|sock)"，结合业务线索（如 curl HTTPS 探测脚本 → dentry 泄漏）；
• 确认版本缺陷后，优先打补丁或设环境变量绕过（如 NSS_SDB_USE_CACHE）。