服务器 Swap 占满了怎么办:从 swappiness 到 OOM Killer 的排查与处理
服务器 Swap 占满了怎么办:从 swappiness 到 OOM Killer 的排查与处理
不少运维同学第一次看到 free -h 里 Swap 一栏被占满都会紧张:内存是不是不够了,要不要马上加内存?先别急。Swap 被用不等于内存耗尽,很多时候它只是内核在做常规的内存腾挪。本文按“先看现场、再定动作”的顺序,讲一次 Swap 占满的标准排查流程。
第一步:先看内存全貌,别只盯 Swap
执行 free -h,重点看三行:Mem 的 available、Swap 的 used,以及 buff/cache 的大小。available 充足、只是 Swap 有占用,大概率是内核把长期不用的匿名页换出去了,属于正常行为;available 接近 0、Swap 持续增长,才是真的内存压力。
再用 vmstat 1 5 看 si(换入)和 so(换出)两列:如果长期是 0,说明 Swap 只是“历史占用”,当前并没有频繁换页,系统并不卡;如果 si/so 持续大于 0,进程在不断换页,性能已经受影响,这时才需要干预。
第二步:找出是谁在吃内存
top 按 M 排序看 RES 列,能快速定位内存大户;要更准一点,用 ps aux --sort=-%mem | head -20 列出前 20 名。注意区分 VIRT 和 RSS:VIRT 包含共享库和映射文件,虚高很常见,真正占用物理内存的是 RSS。
如果怀疑某个进程有内存泄漏,用 cat /proc/<PID>/status | grep -E 'VmRSS|VmSwap' 看它自身的 RSS 和 Swap 占用,再结合 pmap -x <PID> | tail -5 看匿名内存段是否在持续增长。单次快照说明不了泄漏,隔几分钟采两次、对比增长趋势才有结论。
第三步:查 swappiness,理解内核的换出倾向
cat /proc/sys/vm/swappiness 默认一般是 60。这个值越高,内核越积极地把匿名页换到 Swap;值越低,越倾向于保留匿名页、去回收文件缓存。对数据库、缓存类服务,很多人会把它调到 10 甚至 1,减少无谓换页。
临时调整用 sysctl -w vm.swappiness=10,想永久生效就写进 /etc/sysctl.conf 再 sysctl -p。注意:调低 swappiness 并不会把已经换出去的页立刻换回来,它只影响后续行为;想主动把 Swap 清空,可以在内存有富余时执行 swapoff -a && swapon -a,但这一步有风险——如果 available 不足,swapoff 会直接失败甚至触发 OOM,操作前务必确认 available 大于 Swap 已用量。
第四步:OOM Killer 留下的痕迹别漏看
如果服务莫名其妙被杀,先查 dmesg -T | grep -i -A5 'out of memory' 或 journalctl -k | grep -i oom。OOM Killer 被触发时会在内核日志里留下 “Out of memory: Killed process …” 的记录,包括被杀进程的 PID、名字和当时占用的内存。
关键服务可以用 echo -1000 > /proc/<PID>/oom_score_adj 降低被杀优先级(-1000 表示尽量不杀),或者用 echo 500 > /proc/<PID>/oom_score_adj 让次要进程先顶上。但这只是缓兵之计:OOM 频繁触发说明内存规划本身有问题,靠调分数躲不过去。
第五步:分清三种情况,再决定加不加内存
第一种,Swap 有占用但 available 充足、si/so 为 0:不用处理,定期观察即可;第二种,available 长期偏低、si/so 持续大于 0:先找内存大户,确认是业务增长还是泄漏,泄漏先修、增长再考虑加内存或扩容;第三种,OOM Killer 已杀过进程:立即处理,短期可临时加 Swap 文件应急(fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile),长期必须加内存或限流。
应急加 Swap 文件只是给系统争取时间,Swap 换页速度比内存慢几个数量级,长期依赖 Swap 跑业务,性能一定会垮。
小结
Swap 占满先别慌,按顺序做五件事:看 free 与 vmstat 判断是历史占用还是正在换页;用 ps 与 /proc 定位内存大户;查 swappiness 理解换出倾向;翻内核日志确认 OOM Killer 是否动过手;最后按三种情况决定观察、修泄漏还是加内存。把每一次排查的数值记下来,下次再遇到类似告警,对比一下就知道是老问题复发,还是新的增长趋势。
- 点赞
- 收藏
- 关注作者
评论(0)