内存占用高排查:从free到smem
解释 available 与 free 的差别,按进程、缓存、泄漏三条线定位真实占用。下面按“先判断、再动手、最后验证”的顺序展开,每一步都给出可核对的检查点。
涉及 free命令、内存占用高、内存泄漏 的关键动作都写成了具体命令或配置项,可以照着走,也可以当检查表用。
先看 available
free 里的 available 才是可用内存;buff/cache 是缓存,可回收,看到 free 接近 0 不必慌张。
按进程排序
ps aux --sort=-rss 看实际物理内存占用,top 里的 %MEM 在高内存机器上会失真。
共享内存
多进程共享的库在 smem -t -p 里才看得准,用 RSS 相加会重复计算,导致「加起来比总内存还大」。
缓存与释放
drop_caches 只是临时手段,不能解决泄漏;真正判断是否泄漏看长时间趋势而不是瞬时值。
OOM 痕迹
dmesg -T 结合 grep -i oom 能查到底杀了谁,被杀进程往往才是受害者的第一现场。
速查表
| 环节 | 关键动作 |
|---|---|
| 先看 available | free 里的 available 才是可用内存;buff/cache 是缓存,可回收,看到 free 接近 0 不必慌张 |
| 按进程排序 | ps aux --sort=-rss 看实际物理内存占用,top 里的 %MEM 在高内存机器上会失真 |
| 共享内存 | 多进程共享的库在 smem -t -p 里才看得准,用 RSS 相加会重复计算,导致「加起来比总内存还大」 |
| 缓存与释放 | drop_caches 只是临时手段,不能解决泄漏;真正判断是否泄漏看长时间趋势而不是瞬时值 |
常见问题
Q:按文中写法改完,怎么确认真的生效?
不要只看配置文件,用对应的验证命令或从外部视角复测一次;改完先小流量观察一段,再全量推进,出问题能马上回退。
Q:按文中的步骤做完,还需要注意什么?
把处理过程和最终生效的参数记下来。同类问题再出现时直接对照记录,比重查一遍快得多。
Q:业务规模小,也要按这套标准来吗?
不需要一次到位。先把影响最大的两项做到位,剩余的随着业务增长逐步补齐,比一开始就追求完美更容易落地。
小结
回到这篇的 5 个环节:先看 available、按进程排序、共享内存、缓存与释放、OOM 痕迹。把这几个动作写进检查表,下次遇到同类问题按顺序过一遍,比凭经验跳步骤稳。
相关阅读:磁盘扩容:LVM与文件系统在线扩展、crontab写错导致的故障与排查、MySQL慢查询定位与索引优化。
延伸阅读:磁盘扩容:LVM与文件系统在线扩展、Nginx的502与504排查路径、Linux常用命令速查:文件、进程、网络。