swappiness=10不禁止swap，仅倾向回收文件页；当物理内存长期紧张、存在大量冷匿名页、zswap压缩失败或THP导致大页整体换出时，仍会频繁swap。
即使将 vm.swappiness=10，某些业务场景下 swap 仍可能被频繁使用——这不是参数设置失效，而是内核的内存回收逻辑、工作负载特征与系统配置共同作用的结果。
内存压力持续高于可用物理内存
swappiness=10 仅表示“在内存紧张时，内核更倾向回收文件页（page cache）而非匿名页（如堆、栈）”，但它不禁止 swap。当物理内存长期接近耗尽（例如：总内存 64GB，应用常驻占用 60GB+，且 page cache 无法有效释放），内核仍会将部分匿名页换出到 swap，以避免 OOM kill。
- 典型场景：Java 应用堆内存设得过大（如 -Xmx50g），但实际活跃对象少，大量内存处于“已分配但未访问”状态（即 inactive anon pages），这些页容易被 swapout
- 验证方法：
cat /proc/meminfo | grep -E "Active\(anon\)|Inactive\(anon\)|Swap"，观察 Inactive(anon) 高且 SwapUsed 持续增长
应用存在大量“冷匿名页”，且未启用 MADV_DONTNEED 或 mmap(MAP_NORESERVE)
某些服务（如数据库 buffer pool、缓存代理、批处理进程）会预分配大块虚拟内存并长期持有，其中部分页长期未访问。内核将它们归类为 Inactive(anon)，在内存回收时优先 swapout —— 即使 swappiness 值很低。
- 例如：Redis 使用大页（hugetlb）较少时，其内存碎片化导致大量小页处于 inactive 状态；或 Kafka broker 的 log segment 内存映射页在低峰期变冷
- 缓解建议：对可预测生命周期的匿名内存，应用层调用
madvise(..., MADV_DONTNEED)主动丢弃冷页；或启动时加echo 1 > /proc/sys/vm/overcommit_memory配合严格 overcommit 控制
系统启用了 zram/zswap，但压缩失败率高或后端 swap 设备延迟大
若配置了 zswap（压缩后端 swap），而压缩算法无法有效压缩数据（如已加密/随机内容），zswap 会 fallback 到 backing swap（如磁盘 swap 分区）。此时 swappiness=10 仍会触发 swapout，只是路径多了一层压缩尝试。
- 检查命令：
cat /sys/module/zswap/parameters/same_filled_pages_enabled和zswap_stat查看 compress_failures、pool_limit_hit - 若磁盘 swap 在机械硬盘或高 I/O 延迟 NVMe 上，即使少量 swapout 也会因 I/O 阻塞放大感知，表现为“频繁使用”的卡顿感
透明大页（THP）与 swap 行为交互异常
启用 THP（/sys/kernel/mm/transparent_hugepage/enabled = always）时，内核可能将整个 2MB 大页标记为可 swap。一旦其中少量 page 被访问，其余未访问 page 仍随大页整体进入 swap 队列 —— 导致 swap activity 比预期高。
- 常见于容器环境（如 Kubernetes Pod 启用 hugepages）或 PostgreSQL 使用大页缓冲区
- 建议：对 latency 敏感服务，设为
madvice模式，或关闭 THP：echo never > /sys/kernel/mm/transparent_hugepage/enabled
swappiness 是调节策略倾向的杠杆，不是 swap 的开关。真正减少 swap 使用，需结合 workload 特性做组合优化：合理限制进程 RSS、监控 inactive anon 行为、评估是否需要禁用 swap（swapoff -a）、或改用内存优先的架构（如增加 RAM、启用 cgroup memory limits 防止单进程吃光内存）。
