内存泄漏是进程RES/RSS持续上涨、重启归零再涨的典型现象；应盯紧RSS（真实物理内存占用），用watch命令长期监控趋势，排除缓存等干扰后确认泄漏。
直接看 RES 和 RSS，别信 VIRT 或 free 里那个 used。内存泄漏不是“系统变慢了”，而是某个进程的 RES 持续缓慢上涨、重启后归零、再涨——这才是典型信号。
怎么看进程真实内存占用（RES vs RSS）
RES（top 中列）和 RSS（ps 中的 rss 字段）本质是同一个值：进程当前实际占用的物理内存页数。它不包含 swap、不包含未映射的虚拟地址、也不含共享库重复计算的部分——这才是你该盯死的数字。
-
top启动后按 大写 M，按RES降序，一眼揪出吃内存的进程 -
ps aux --sort=-%mem | head -10快速列出内存 Top 10，%MEM是RSS占系统总物理内存的百分比 - 别被
VIRT骗：它含 mmap 区、未分配的虚拟地址、甚至保留但没用的地址空间，Java 进程动辄几十 GBVIRT很正常，RES才是真压力 -
free -h的used列包含 cache/buffer，available才是可用余量；但这个值下降 ≠ 某个进程泄漏，只是整体压力上升
确认是不是泄漏：持续观察 + 对比基线
单次快照没意义。泄漏是时间维度上的异常增长，必须拉长时间线对比。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 用
watch -n 30 'ps -p <PID> -o pid,comm,rss,vsz,%mem --no-headers'每 30 秒抓一次目标进程的RSS，跑几小时看趋势 - 如果
RSS在无业务增长、无缓存预热、无连接数上升的前提下，稳定爬升（比如每小时 +50MB），基本可锁定泄漏 - 重启进程后
RSS归零，过几小时又回到相同增长斜率——这是泄漏最扎实的证据 - 注意排除干扰：JVM 的
-Xmx限制内堆增长、Go 的GOGC行为、或 mmap 文件读取缓存累积，这些不是泄漏，是预期行为
定位泄漏点：valgrind 是 C/C++ 的首选，但有硬约束
valgrind --leak-check=full 能精准报出 definitely lost 地址和调用栈，但它只适用于用户态、可重编译、且能接受 10–30 倍性能衰减的场景。
- 必须让进程**完整退出**才能生成泄漏报告；服务类进程得发
SIGTERM（kill -15），不能kill -9 - 动态链接库路径要提前设好：
export LD_LIBRARY_PATH=./lib:$LD_LIBRARY_PATH，否则符号无法解析 - 日志里重点搜
definitely lost，忽略still reachable（通常是全局变量或 main 退出前未 free） - 输出堆栈是**从下往上读**：最后一行是你代码里 malloc/new 的位置，上面是调用链；
authorize_server_get_safenet_info这种函数名直接暴露问题模块 - 生产环境禁用：它会让进程卡顿、内存翻倍，只用于测试环境复现
内核级泄漏或 Java/Go 等语言怎么办
用户态工具失效时，得切到内核视角或语言特有机制。
- 怀疑内核泄漏？看
/proc/meminfo里的Slab、SReclaimable是否随时间上涨；再用slabtop -o排序，重点关注size-4096、dentry、inode_cache等高频分配项 - Java 进程别只看
top RES：它含堆外内存（Netty direct buffer、JNI）、Metaspace、CodeCache。用jstat -gc <PID>看堆内 GC 后是否回落，再用jcmd <PID> VM.native_memory summary查堆外 - Go 程序用
pprof：启动时加net/http/pprof，访问/debug/pprof/heap?debug=1看实时分配栈，注意区分inuse_space（当前持有）和alloc_space（历史总分配） -
pmap -x <PID>可以看出进程各内存段大小，特别关注匿名映射区（[anon]）是否异常膨胀，这往往是泄漏的落脚点
真正难的不是发现 RSS 在涨，而是区分它是泄漏、缓存、还是设计如此。很多“泄漏”最后发现是配置了超大 shmmax 却没清理共享内存，或是 systemd 日志刷爆了 journald 缓冲区——得一层层排除，而不是一上来就上 valgrind。
