swappiness=0仍swap？zone_reclaim_mode与numa_balancing冲突解析

在NUMA系统中，即使将swappiness设为0，Linux内核仍可能意外触发swap，根源在于numa_balancing与zone_reclaim_mode的隐式协同：当numa_balancing尝试将页面迁移到本地节点而目标zone内存不足时，若vm.zone_reclaim_mode启用了bit 2（即值含2），内核会强制执行swap回收，完全无视swappiness=0的策略；因此，真正禁用非预期swap需双管齐下——将zone_reclaim_mode设为0并关闭numa_balancing，否则所谓“零swap”只是脆弱的假象。

swappiness=0 为什么还在用 swap

Linux 设置 swappiness=0 并不等于“完全禁用 swap”，它只是让内核极度倾向保留匿名页在内存中，但某些路径仍会绕过该策略触发 swap。最常见的是 NUMA 场景下 numa_balancing 启用时，内核会主动迁移页面到远端节点内存不足的 zone，而当目标 zone 的空闲内存低于水位时，就会触发 zone_reclaim —— 此时哪怕 swappiness=0，也会回退到 swap 回收（而非直接 OOM 或等待），因为 zone_reclaim 的 swap 回收逻辑不尊重 swappiness 值。

vm.zone_reclaim_mode 是什么角色

vm.zone_reclaim_mode 控制本地内存回收行为，取值为位掩码组合：

• 1：启用本地 zone 回收（即不跨 NUMA 节点分配）
• 2：允许在 zone 回收时 swap（关键！此标志无视 swappiness）
• 4：允许在 zone 回收时回收文件页（如 page cache）

默认值是 0，但在 NUMA 系统上，部分发行版或内核配置可能默认设为 1 或 3。只要启用了 bit 2（即值包含 2），zone_reclaim 就会在内存压力下直接 swap 页面，跳过 swappiness 判断。

numa_balancing 如何触发 zone_reclaim

numa_balancing 默认开启（/proc/sys/kernel/numa_balancing = 1），它周期性扫描进程页表，标记访问热点，并尝试把页面迁移到当前 CPU 所在 node。迁移过程调用 alloc_pages_current() → __alloc_pages_nodemask() → 若目标 node 的 zone 内存不足且 zone_reclaim_mode & 2，就走 zone_reclaim() → 最终调用 try_to_free_pages() 并强制启用 swap 回收分支。

也就是说：numa_balancing 本身不直接 swap，但它制造了跨 zone 分配压力；而 zone_reclaim_mode=2 是那个真正执行 swap 的开关。

如何彻底关闭非预期 swap

要让 swappiness=0 生效，必须阻断所有绕过它的路径：

• 确认 vm.zone_reclaim_mode 不含 bit 2：运行 sysctl vm.zone_reclaim_mode=0 或 echo 0 > /proc/sys/vm/zone_reclaim_mode
• 若不需要 NUMA 页迁移，关闭 numa_balancing：写入 0 到 /proc/sys/kernel/numa_balancing
• 检查是否启用了透明大页（THP）的 always 模式，它也可能在迁移时加剧 zone 压力，建议设为 madvise
• 验证：用 cat /proc/vmstat | grep -E "pgpgin|pgpgout|pswpin|pswpout" 观察 swap I/O 是否归零；同时监控 /sys/devices/system/node/node*/meminfo 中各 node 的 MemFree 和 SwapCached

NUMA 环境下，swappiness=0 只是半截刹车——真正的制动点在 zone_reclaim_mode 和 numa_balancing 的组合开关上，漏掉任意一个，swap 就可能悄悄回来。

今天关于《swappiness=0仍swap？zone_reclaim_mode与numa_balancing冲突解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！