排查资源泄漏关键看“该不该涨、有没有停”，linux中最常泄漏的是文件描述符和内存，需按“现象定位→资源分析→行为验证”主线，结合fd分布、内存增长模式及调用行为追踪精准识别根因。
排查进程资源泄漏，关键不是看“用了多少”，而是看“该不该涨、有没有停”。Linux 中最常泄漏的两类资源是文件描述符（FD）和内存，它们表现不同、排查路径也不同，但都遵循“现象定位 → 资源分析 → 行为验证”这一主线。
先盯住异常进程：用轻量命令秒级锁定目标
别一上来就跑 perf 或 lsof——这些工具自身会开销，可能干扰判断。先用系统原生接口快速筛出嫌疑对象：
- 查高 FD 进程：for pid in /proc/[0-9]*; do p=$(basename $pid); c=$(ls -1 "$pid/fd" 2>/dev/null | wc -l 2>/dev/null); [ "$c" -gt 200 ] && echo "$p $c"; done | sort -k2 -nr | head -5 ——比 lsof 快且不依赖外部工具
- 查高内存进程：ps aux --sort=-%mem | head -5，重点关注 RES 持续上升、VIRT 明显大于 RES 的进程
- 确认是否真卡限：cat /proc/
/limits | grep "Max open files" 看 soft limit 是否已逼近；cat /proc/sys/fs/file-nr 看第二列是否接近第三列（file-max）
区分泄漏类型：看 FD 分布或内存增长模式
数量只是表象，类型才是线索：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
FD 泄漏典型信号：lsof -p
| awk '{print $5}' | sort | uniq -c | sort -nr 后重点看：
– 大量 REG (deleted)：文件被 unlink 但句柄未关，磁盘空间不释放
– 大量 anon_inode（如 eventfd/timerfd）：事件循环没退出、线程池未 shutdown
– 大量 sock CLOSE_WAIT/ESTABLISHED 且无连接复用逻辑：HTTP 客户端没读完 response body、socket 忘关 -
内存泄漏典型信号：watch -n 1 'cat /proc/
/status | grep -E "VmRSS|VmSize"' 观察 RSS 是否持续单向爬升；若 VmSize（VIRT）涨得快但 RSS（RES）几乎不动，大概率是 malloc 了但没 touch，属于虚占非实漏
验证调用行为：抓运行时 open/malloc 是否成对
代码没看全前，先让系统自己说话：
- 对 FD 泄漏：perf trace -e syscalls:sys_enter_openat,sys_enter_close,syscalls:sys_enter_creat -p
实时跟踪打开/关闭动作，看是否有 open 多、close 少、或 close 失败的情况 - 对内存泄漏：sudo cat /proc/
/maps | awk '$6 ~ /heap/ {print $1}' 找堆地址范围，再用 pstack查当前调用栈，结合业务逻辑判断是否在反复 new/malloc 未 free - 生产环境慎用 Valgrind（性能降 10–50 倍），可优先用 gdb -p
+ info proc mappings + x/100xg 辅助观察堆内存碎片化程度
关联常见泄漏点：直奔高频根因
多数泄漏不是随机发生，而是落在几个经典场景里：
-
Java 进程：关注 jstat -gc
中老年代持续增长、Full GC 频次升高；检查 ThreadLocal 未 remove、静态集合类不断 add、NIO Direct Buffer 未 clean -
Go 进程：用 go tool pprof http://
/debug/pprof/heap 看 top alloc_objects；注意 goroutine 持有大对象、sync.Pool 误用、defer 中未释放资源 - C/C++ 进程：检查日志轮转逻辑中 fopen 未 fclose、网络服务中 accept 后未 close client fd、异常分支遗漏 free、结构体内存未整体释放
