swap使用率高但anon page少，根本原因是vm.swappiness控制回收倾向而非开关，当file-backed page cache回收慢于内存分配时，内核会将干净或脏的file页换出到swap；可通过调高vfs_cache_pressure、降低dirty_ratio、启用zram等优化。
为什么 swap 使用率高但 anon page 很少？
这通常不是内存泄漏或进程异常，而是内核在压力下优先回收 file-backed page cache，但回收不及时或策略偏保守，导致 swap 被迫介入——哪怕匿名页（anon page）本身不多。根本原因是：Linux 的 vm.swappiness 控制的是“倾向性”，不是“开关”；当 page cache 回收慢于内存分配速率时，内核会把部分干净的 file-backed 页先换出到 swap（尤其是那些刚被访问过、尚未写回磁盘的 dirty page），以腾出内存给新分配。
-
swappiness=60（默认）下，内核对 file-backed 和 anon page 的回收权重接近，但实际调度还受lruvec状态、refault rate、workingset 活跃度影响 - 若 workload 频繁读大文件（如日志归档、数据库 backup）、且文件未被再次访问，这些 page cache 会快速进入
inactive_fileLRU 链表，但内核可能因vm.vfs_cache_pressure偏低或dirty_ratio限制而延迟回写 - 观察
/proc/vmstat中的pgpgout和pswpout，若后者显著高于前者，说明 swap 写入主力是 file-backed 页（即 “swap-in file cache” 场景）
如何让 file-backed page cache 更快被回收？
核心思路是降低内核对 file cache 的“留恋程度”，同时加速其回写和释放路径：
- 把
vm.vfs_cache_pressure从默认100提高到150–200：增强 dentry/inode cache 回收力度，间接减少 page cache 引用计数滞留 - 适当调低
vm.dirty_ratio（如20）和vm.dirty_background_ratio（如10）：让脏页更早触发回写，避免积压后一次性刷盘阻塞回收 - 启用
vm.drop_caches=2（仅临时调试）可强制清空 page cache，验证是否为 cache 积压导致；但生产环境禁用，应靠参数长期调控 - 若使用 ext4/xfs，确认挂载选项含
barrier=1和commit=30，避免日志提交延迟拖慢 dirty page 生命周期
swap 分区/文件是否真有必要保留？
不一定。当 anon page 很少、且 workload 不依赖 swap for hibernation 或 kdump，swap 实际只在 page cache 回收卡顿时“背锅”：
- 可尝试禁用 swap：
swapoff -a，观察 OOM 是否立即发生；若只是pgmajfault上升、无 crash，则说明系统本可靠 page cache 动态回收支撑 - 若必须保留 swap（如云主机要求），建议改用
zram：它把压缩后的 page（包括 file-backed）存于内存，避免磁盘 I/O 成为瓶颈，且zram的disksize可设为物理内存的 25%～50%，比传统 swap 更适配 cache-heavy 场景 - 注意：启用
zram后需调低vm.swappiness至10–30，否则内核仍倾向换出而非压缩
排查时最容易忽略的点
-
/proc/meminfo 中的 Inactive(file) 和 Active(file) 差值大，不代表问题；要看 pgpgin/pgpgout 与 pswpin/pswpout 的比值——如果后者占总换页量 >30%，才是 file-backed 导致 swap 高
-
perf record -e 'mm_vmscan_lru_isolate' -a 可抓取实际哪些 LRU 链表被扫描，确认是不是 inactive_file 长期滞留未被隔离
- 容器环境（如 Docker/K8s）中，cgroup v1 的
memory.limit_in_bytes 可能导致子系统回收逻辑失真，v2 下需检查 memory.pressure 和 memory.low 设置是否合理
/proc/meminfo 中的 Inactive(file) 和 Active(file) 差值大，不代表问题；要看 pgpgin/pgpgout 与 pswpin/pswpout 的比值——如果后者占总换页量 >30%，才是 file-backed 导致 swap 高 perf record -e 'mm_vmscan_lru_isolate' -a 可抓取实际哪些 LRU 链表被扫描，确认是不是 inactive_file 长期滞留未被隔离 memory.limit_in_bytes 可能导致子系统回收逻辑失真，v2 下需检查 memory.pressure 和 memory.low 设置是否合理 真正卡住回收的，往往不是参数本身，而是 page cache 所属文件的访问模式突然变化（比如备份任务结束但缓存未老化）——此时再激进的 swappiness 也救不了，得靠 workload 层主动 posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) 或定期 drop_caches（配合业务低峰）。
