vm.swappiness=0并不禁用swap，仅抑制非必要匿名页换出；内存耗尽时仍可能触发swap或OOM。需结合负载、硬件与内核版本综合调优。
vm.swappiness 是什么，设成 0 就不 swap 了吗
vm.swappiness 是内核参数，控制内存回收时倾向使用 swap 的“积极性”，取值范围是 0–100。它不决定是否启用 swap，而是影响“多早、多频繁地把匿名页（如进程堆、栈）换出到 swap 区”。设为 0 并不等于禁用 swap —— 当物理内存彻底耗尽且无法回收 page cache 时，Linux 仍可能触发 OOM killer 或 fallback 到 swap（尤其在 5.8+ 内核中，vm.swappiness=0 仅抑制非必要换出，不保证完全规避）。
常见误判现象：free -h 显示 swap used 为 0，但 cat /proc/swaps 仍列出 swap 分区；或系统空闲时 swapon --show 显示活跃，但 grep -i swap /proc/vmstat 中 pgpgin/pgpgout 无增长 —— 这说明 swap 已加载但未被实际使用，和 vm.swappiness 设置无关，只和当前内存压力有关。
不同负载场景下推荐的 swappiness 值
没有全局最优值，必须结合工作负载特征调整：
- 数据库服务（PostgreSQL/MySQL）、内存密集型 Java 应用：建议设为
1或0。这类应用依赖大块连续物理内存，频繁 swap 会直接拖垮响应延迟；page cache 可让步，但匿名页换出代价极高 - 桌面环境或开发机（多浏览器+IDE+容器）：
60是默认值，通常可用；若常开几十个 Chrome 标签，可尝试30～40，平衡前台响应与后台进程驻留 - 运行 Docker/Kubernetes 的服务器：若容器内存限制严格且启用了
memory.swap.max，宿主机层面vm.swappiness建议 ≤10，避免内核与 cgroup swap 策略冲突导致不可预测换出 - 嵌入式或内存极小设备（≤2GB RAM）：可设为
80～100，但需确保 swap 分区足够（≥RAM×1.5），否则容易触发 OOM
如何安全修改并验证效果
临时修改（重启失效）：sudo sysctl vm.swappiness=1；永久生效需写入 /etc/sysctl.conf 或独立配置文件（如 /etc/sysctl.d/99-swappiness.conf），内容为 vm.swappiness = 1。
验证是否生效：cat /proc/sys/vm/swappiness；观察是否真正减少 swap 使用：watch -n 1 'grep -E "Swap|pgpg" /proc/vmstat'，重点关注 pgpgout（每秒换出页数）是否下降，同时用 slabtop -o 看 slab_reclaimable 是否稳定 —— 若调低后 pgpgout 几乎为 0，但 slab_reclaimable 持续飙升且 MemAvailable 快速收缩，说明 page cache 回收不足，可能需同步调高 vm.vfs_cache_pressure。
容易踩的坑：
- 修改后未运行
sudo sysctl --system（对.conf文件生效）或sudo systemctl restart proc-sys-fs-binfmt_misc（某些发行版需要） - 误以为调低就能“释放 swap”，实际上
swapoff -a && swapon -a才能清空已换出数据，但该操作会触发大量内存重装，可能导致瞬时卡顿甚至 OOM - 监控时只看
free输出，忽略/proc/meminfo中的Inactive(anon)和Active(anon)—— 这两个值更能反映匿名页的冷热分布，比 swap 使用量更早暴露换出倾向问题
比 swappiness 更关键的底层因素
很多性能问题根源不在 vm.swappiness，而在 swap 设备本身和内存布局：
- swap 分区在机械硬盘上？哪怕
swappiness=1，一次换出也可能阻塞数百毫秒 —— 优先考虑用zram（压缩内存）替代传统 swap，启动即生效：sudo modprobe zram num_devices=1 && echo 1G > /sys/class/zram-control/hot_add - NUMA 架构服务器（如双路 Xeon）未绑定内存节点？进程在 Node 0 分配内存，却因
swappiness触发换出到 Node 1 的 swap 分区，跨节点访问放大延迟 —— 此时应先用numactl --membind=0 --cpunodebind=0 your_cmd约束，再调参 - 内核版本低于 4.12？旧内核的 LRU 链表管理粗糙，
swappiness调节粒度粗，建议升级或改用vm.watermark_scale_factor配合调优
真正起效的调优永远从 workload 特征和硬件约束出发，vm.swappiness 只是最后一层杠杆。改完记得压测——用 stress-ng --vm 2 --vm-bytes 80% -t 300s 模拟压力，再看 iostat -x 1 和 pidstat -r 1 的交叉输出，否则数值再“合理”也只是纸上谈兵。
