登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

Linux swap 使用升高怎么判断:vmstat 的 si/so、swappiness 与回收边界

来源:17golang原创

时间:2026-08-25 09:47:45 458浏览 收藏

线上机器的 swap 从几百 MiB 慢慢涨到数 GiB,最容易出现的误判是“内存泄漏了,赶紧关掉 swap”。其实,swap 已用量是历史结果,真正要看的是系统现在是否还在持续换页:vmstat 1 中的 siso 是否连续增长,free 的 available 是否逼近压力线,以及磁盘 I/O 是否被换页拖慢。

要点速览

  • swap 使用量高只说明曾经有页面被换出,不能单独证明当前内存不足。
  • vmstatsi/so 连续非零,才说明正在发生明显的换入换出。
  • 处理顺序应是留证、确认压力来源、控制负载,再评估 swappiness 或扩容。
  • 关闭 swap 或清空 swap 会制造新的 I/O 和内存压力,不应作为第一步。

先把“swap 已用”与“正在换页”分开

假设一台 api-worker 机器有 32 GiB 内存,swap 已用 4 GiB,但最近十分钟接口延迟没有明显变化。此时先不要改 sysctl。内核可能只是把一批长期不活跃的匿名页换出,让文件页缓存留在内存里;如果这些页没有被重新访问,swap 数字会保持不变,却不代表系统正在抖动。

反过来,swap 只有 512 MiB 也不能掉以轻心。只要业务线程不断从 swap 换回页面,短时间内的延迟就可能已经受影响。判断关键在“变化速率”和“业务症状”,不是某个绝对占用百分比。

用 vmstat 抓住换入换出的现场

先连续采样,不要只看一行快照:

vmstat 1 10
free -h
cat /proc/sys/vm/swappiness

vmstat 输出中,swpd 是已使用的 swap 大小,si 是从磁盘换入的内存量,so 是换出的内存量。单次采样出现数值并不能说明趋势;更有价值的是连续多个采样周期里 si/so 都不为零,并且伴随响应时间、运行队列或磁盘等待上升。

Linux swap 历史占用与持续换页的对照:swpd 保持不变时 si 和 so 接近零,持续换页时两者连续增长

free -h 中优先看 available,不要把 free 一栏当成“还能用的全部内存”。文件缓存可以在需要时回收,available 更接近内核对新分配的估计。若 available 仍宽裕、si/so 接近零,swap 已用量本身通常不是眼前故障。

把内存压力和磁盘压力放到同一张证据表

持续换页时,下一步要分辨是整机内存真的紧张,还是某个进程的工作集突然扩大。可以在同一时间窗口补充三类读数:

  • 内存:free -hcat /proc/meminfo,关注 MemAvailable、SwapFree 和 CommitLimit。
  • 进程:ps -eo pid,comm,%mem,rss --sort=-rss | head,先找出 RSS 最大且持续增长的进程。
  • 设备:iostat -xz 1 5,观察交换设备的 await、util 和队列,而不是只看 CPU 使用率。

如果 available 很低、si/so 连续增长、交换设备 await 明显抬高,同时业务延迟上升,这是一条比较完整的内存压力证据链。若只有 swpd 较高,其他指标平稳,则更像“曾经换出过但目前没有持续活动”。

swappiness 是选择倾向,不是内存上限

/proc/sys/vm/swappiness 控制内核在文件页回收与交换之间的相对倾向,内核文档将它描述为交换 I/O 与文件系统分页相对成本的控制值,范围为 0 到 200。它不是“允许使用多少 swap”的阈值,也不能修复泄漏、错误的缓存策略或过大的进程工作集。

sysctl vm.swappiness
sudo sysctl -w vm.swappiness=40

临时修改前应记录旧值,先在低峰或一台灰度机器上观察。对于 zram、zswap 或高速 NVMe,交换 I/O 成本和普通磁盘不同,不能照搬别人的数值。需要持久化时再写入发行版实际加载的 sysctl 配置,并重启后复查;不要把一次 sysctl -w 的结果误当成长期验收。

三种处理选择,按证据决定先后

只是历史占用:先保留现场,不急着清空

当 si/so 基本为零、available 稳定、业务没有延迟抖动时,优先记录当前值和采样时间,继续观察。贸然执行 swapoff 可能要求内核把页面搬回 RAM,反而造成瞬时内存压力。

持续换页:先降低负载或缩小工作集

先检查最近部署、批处理、缓存容量和进程 RSS 曲线,必要时暂停非关键批任务或降低并发,再复查 vmstat。若有 OOM killer、cgroup memory.events 或容器限制证据,应沿着对应的资源边界处理,不要只调全局 swappiness。

容量长期不足:扩容或重新规划交换介质

如果在正常峰值下长期出现低 available、持续 si/so 和高磁盘等待,调一个更低的 swappiness 只能改变回收顺序,不能增加物理内存。此时应评估增加内存、拆分工作负载、调整缓存上限或使用更合适的交换介质,并把变更纳入回滚方案。

Linux 内存压力判断路径:从 vmstat 的 si/so 到 free、iostat、进程 RSS,再决定负载控制、参数灰度或扩容

几个看起来合理、实际风险很高的动作

  • 直接 swapoff -a:只有在确认可用内存足够并安排窗口时才考虑,执行前保留监控和回滚路径。
  • 看到 swap 高就调成 0:这会压低主动换出的倾向,却可能把文件页回收和内存分配压力推到别处。
  • 只看 top 的 %MEM:它无法解释文件缓存、cgroup 限制和换页 I/O,必须与 vmstat、free 和设备指标交叉。
  • 把一次采样当结论:换页是时间序列问题,至少覆盖业务高峰和低峰两个窗口。

常见问题与现场速查

swap 已用很多,但 si 和 so 一直是 0,需要清理吗?

通常不需要因为占用量本身立刻清理。先确认 available、业务延迟和磁盘等待都稳定,再把它作为历史状态记录下来。

si 和 so 哪个更值得关注?

两者都要看。so 说明页面被换出,si 说明访问时又从交换设备换回;连续的 si 往往更直接地对应工作集被反复触碰,但应结合业务延迟判断。

swappiness 应该设置成多少?

没有脱离负载和交换介质的通用答案。先记录基线,在灰度主机调整并观察 si/so、I/O 延迟和应用指标,再决定是否持久化。

什么时候应该优先扩容?

当正常业务峰值下仍持续换页,且 available 长期偏低、设备等待和业务延迟同步上升时,扩容或拆分负载比反复调参更可靠。

判断 swap,先问“现在是否在换页”,再问“为什么会换页”,最后才决定“参数要不要改”。这条顺序能避免把一个历史数字误判成故障,也能让真正的内存压力留下可复查的证据。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>