free -h看 available 列,它才代表真正还能用多少。
约 1168 字大约 4 分钟
2026-05-14
“内存告警了”——但内存到底是真不够,还是只是缓存占得多?是哪个进程在吃,还是发生了 OOM?这篇是一份照着走的排查清单,先判断真假、再定位元凶。背后的原理见 内存、缓存与 swap。
按“看 available 判断真假 → 找吃内存的进程 → 查 swap 抖动 → 查 OOM 记录”的流程排查内存问题。
free -h看 available 列,它才代表真正还能用多少。
ps aux --sort=-%mem | head按内存占用排序,揪出 RSS 最高的进程。
vmstat 1si/so 持续不为 0,说明在频繁换入换出。
journalctl -k | grep -i oom内核有没有因内存耗尽杀过进程。
收到内存告警,先 free -h,但别盯着 free 这一列——盯 available:
total used free buff/cache available
Mem: 7.7G 2.1G 180M 5.4G 5.2Gfree 只剩 180M 不代表内存不够——5.4G 是 Linux 拿来做磁盘缓存的,应用要用随时能回收。available(5.2G)才是真正可用的量。available 还很充裕,就不是内存问题,告警可能是阈值设得太敏感。
确认 available 确实低,下一步揪进程:
ps aux --sort=-%mem | head # 按内存排序,看 RSS 列看 RSS(实际占用的物理内存)最高的几个。是某个应用内存泄漏一直涨,还是本来就是个内存大户(数据库、JVM)?结合它的日志(见 日志系统基础)判断。
vmstat 1 # 盯 si / so 两列si(换入)和 so(换出)持续不为 0,说明系统在内存和磁盘之间反复倒腾——这叫 swap 抖动,性能会断崖式下降。注意:有 swap 占用不等于有问题,频繁换入换出才是。
如果现象是“某个服务莫名其妙就没了”,几乎一定要查 OOM:
journalctl -k | grep -i oom
dmesg | grep -i oom看到 Out of memory: Killed process ...,就坐实了内存被耗尽、内核杀了进程自救。OOM 日志会告诉你它杀的是谁——那个进程不一定是“元凶”,但一定是“受害者”,顺着它往上查。
free -h 看 available → 充裕就不是内存问题,结束。ps --sort=-%mem 找吃内存的进程。vmstat 1 → swap 在不在抖动,判断压力程度。journalctl -k | grep oom → 有没有已经发生过 OOM。走完这四步,你能说清“内存到底有没有问题、是谁的问题、严不严重”。
别用 drop_caches、别盲目加 swap 来“解决”内存问题
两个常见的错误“修复”:① echo 3 > /proc/sys/vm/drop_caches 清缓存——你只是丢掉了有用的缓存,系统接着还得重新读,反而更慢;② 内存不够就拼命加 swap——swap 抖动只会让系统更卡,治标不治本。真正该做的是定位吃内存的进程、优化它(或修内存泄漏)、或者确实需要就加物理内存。kill 掉内存大户之前也要确认它是不是核心业务进程。
| 误区 | 更稳妥的做法 |
|---|---|
看 free 列小就判定内存不够 | 看 available,它算上了可回收的缓存 |
| 看到有 swap 占用就当故障 | 看 vmstat 的 si/so,频繁抖动才是问题 |
| 服务“消失”了不查 OOM | `journalctl -k |
| 用 drop_caches / 加 swap “解决”内存问题 | 定位吃内存的进程并优化,必要时加物理内存 |
版权归属:Shuo Liu