快速定位高内存进程应先用htop或top按内存排序查看RES和%MEM，再用ps命令抓取前10名；深入分析需检查/proc/PID/status、pmap和smaps；注意区分真实占用与缓存，结合free、vmstat、smem和slabtop综合判断，并通过watch、日志采样及专用工具验证趋势与泄漏。
快速定位高内存进程
先用交互式工具一眼看出谁在“吃”内存。运行 htop（如未安装，sudo apt install htop 或 sudo dnf install htop），默认就按内存从高到低排序，RES 列代表实际占用的物理内存，%MEM 是占比，比对两者更准——有些进程 RES 高但 %MEM 低，可能是系统总内存大、单个进程占比不显眼。
若只能用基础环境，top 同样有效：启动后按 Shift + M（大写 M）切换至内存排序；再按 u 可筛选指定用户，k 可杀进程（务必确认后再操作）。
非交互场景下，用 ps 一键抓取前 10 名：
-
ps aux --sort=-%mem | head -n 10—— 看整体内存占比排名 -
ps -eo pid,comm,%mem,rss,vsize --sort=-rss | head -n 10—— 更关注实际物理内存（RSS）占用
深入看单个进程的内存构成
找到可疑 PID 后，别只盯 RSS。Linux 进程内存分得很细，关键要看它到底用了什么类型的内存：
-
cat /proc/<pid>/status | grep -i "vm\|rss\|anon\|file"</pid>重点关注：VmRSS（等同 RES）、RssAnon（堆/栈等匿名内存）、RssFile（共享库、mmap 文件等） -
pmap -x <pid></pid>—— 显示每段内存的大小、权限和映射来源，能快速识别是否某块 mmap 区域异常膨胀 -
cat /proc/<pid>/smaps | awk '/^Size:/ {sum+=$2} END {print sum}'</pid>—— 统计该进程总虚拟内存（KB），辅助判断是否地址空间失控
特别注意：如果 RssAnon 远高于 RssFile，且持续增长，大概率是堆内存泄漏；如果 RssFile 占比极高，可能是缓存了大量文件或共享库加载异常。
区分“真占”和“假高”：缓存、共享与可回收性
看到 free -h 显示 used 很高，别急着杀进程。Linux 会把空闲内存自动用于 buff/cache，这部分在应用需要时会立即释放：
-
free -h中重点看 available 值——这才是真正可分配给新进程的内存 - 若 available 很低，再查
vmstat 1 5：持续出现 si > 0（swap in）或 so > 0（swap out），说明物理内存已严重不足，开始频繁换页 - 共享内存（SHR）在 top/htop 中会重复计算，用 smem 更准：
smem -s rss -r | head -n 10显示 PSS（按比例分摊后的实际开销）
另外，slab 缓存（尤其是不可回收的 dentry/inode）也可能悄悄吃掉大量内存：slabtop -o | head -n 20 查看 top 占用 slab 的对象。
辅助验证与长期观察
单次快照容易误判，建议结合时间维度确认趋势：
- 用
watch -n 2 'free -h'每 2 秒刷新一次，观察 available 是否持续下降 - 记录一段时间内 top 内存进程变化：
top -b -n 3 -d 5 | grep -A 10 "%MEM" > mem.log（采样 3 次，间隔 5 秒） - 怀疑内存泄漏又无法停服务？可用
valgrind --tool=memcheck --leak-check=full --log-file=valgrind.log ./your_program在测试环境复现（生产慎用）
对于 Java、Node.js 等运行时环境，还需结合其自身工具：jstat、jmap 或 process.memoryUsage()，不能只依赖系统层指标。
