swappiness=1仍会触发swap，因内存压力不仅源于物理内存耗尽，还来自PageCache回收受阻、cgroup内存限制、memcg soft limit突破或NUMA节点局部耗尽等隐性因素。
为什么 swappiness=1 仍会触发 swap？关键在「内存压力」不只来自物理内存耗尽
设置 swappiness=1 并不等于禁用 swap，它只是大幅降低内核主动换出匿名页的倾向。真正触发 swap 的往往是隐性内存压力：比如 PageCache 回收受阻、cgroup 内存限制、或 memcg 的 soft limit 被突破。此时即使 free -h 显示还有数 GB 空闲内存，内核仍可能为满足内存分配请求而 swap 出部分匿名页。
vm.vfs_cache_pressure 过高会间接加剧 swap 活动
该参数控制内核回收 dentry 和 inode 缓存的积极程度。值过高（如默认 100 或设为 200）会导致 PageCache 被过度回收，从而降低文件读写缓存命中率，迫使应用更频繁地分配新页、放大内存分配压力。尤其在大量小文件 I/O 场景下，这会显著抬升 pgmajfault 和后续 swap 倾向。
- 建议观察
/proc/vmstat中的pgpgin/pgpgout和pgmajfault变化趋势 - 若
pgmajfault持续偏高且伴随pgpgout上升，可尝试调低vm.vfs_cache_pressure至 50–80 - 调整后需配合
echo 2 > /proc/sys/vm/drop_caches清理旧缓存（仅测试用），否则效果不明显
cgroup v1/v2 的 memory.limit_in_bytes 是 swap 的隐形开关
当进程运行在 cgroup 中（常见于容器、systemd service），其实际可用内存由 memory.limit_in_bytes（v1）或 memory.max（v2）硬性约束。一旦该限制被触及，内核会在该 cgroup 内部触发内存回收——包括 swap。此时 swappiness 全局设置完全失效，cgroup 自身的 memory.swappiness 才起作用（v1）或由 memory.swap.max 控制（v2）。
- 检查
cat /sys/fs/cgroup/memory/<your-cgroup>/memory.swappiness</your-cgroup>，常为 60（非继承全局值） - systemd 服务可通过
MemoryLimit=和MemorySwapMax=单独配置，不设MemorySwapMax默认允许使用全部 swap - 用
systemctl show <unit> | grep -i mem</unit>快速确认当前限制
NUMA 节点不均衡导致局部内存耗尽，触发 swap
在多插槽服务器上，若进程绑定到某 NUMA 节点（如通过 numactl --cpunodebind=0 --membind=0），但该节点本地内存已满，而其他节点仍有空闲，内核默认不会跨节点分配（除非启用 zone_reclaim_mode=1）。结果是：该节点触发直接回收，优先 swap 匿名页，而非迁移页面或从远端分配。
- 用
numastat -p <pid></pid>查看进程各节点内存分布 - 用
cat /sys/devices/system/node/node*/meminfo | grep MemFree对比各节点空闲量 - 临时缓解可设
echo 1 > /proc/sys/vm/zone_reclaim_mode，但会增加延迟，生产环境慎用
free 或 top 里的压力源：cgroup 边界、NUMA 局部性、vfs cache 失衡。swap 不是“内存不够”的简单信号，而是内核在多重约束下权衡的结果。 
