安全循环开关刷新swap需满足三前提：memavailable≥swap已用量、优先用swap文件、避开业务高峰；执行swapoff -a && swapon -a后应调低swappiness至10并立即排查泄漏根因。

当系统因内存泄漏导致 Swap 使用率持续攀升甚至爆满时，单纯重启或粗暴 kill 进程风险高、不可控。所谓“安全循环开关刷新内存置换队列”，本质是**在不中断关键服务的前提下，临时清空 Swap 并促使内核重新评估页面活跃性，让真正冷的数据回写、热的数据保留在物理内存中**。这不是万能解药，但可缓解 OOM 风险并为排查争取时间。

确认当前 Swap 和内存真实压力

先排除误判：Swap 100% ≠ 内存真的不够用。重点看 available（真正可用内存）和 swap used / total 比值，同时检查是否有进程 RES 持续上涨：

• 运行 free -h，关注 available 是否持续低于 500MB（对 16G+ 系统）；
• 运行 swapon -s 确认 Swap 设备路径；
• 运行 cat /proc/meminfo | grep -E "MemAvailable|SwapTotal|SwapFree" 获取精确数值；
• 用 top -o %MEM 或 ps aux --sort=-%mem | head -10 快速定位异常 RES 占用进程。

执行安全的 Swap 刷新操作

核心是 swapoff -a && swapon -a，但需满足三个前提才“安全”：

swap-master汇率PHP库

swap-master汇率PHP库

下载

• 物理内存必须有足够余量：执行前确保 MemAvailable > Swap 已使用量（例如 Swap used=6G，则 MemAvailable 至少要 ≥7G），否则 swapoff 会直接触发 OOM Killer；
• Swap 是文件而非分区时更稳妥：Swap 文件（如 /swapfile）关闭后数据已加载回内存（若空间够），再启用只是重建映射；Swap 分区则需完整读写，耗时略长；
• 避免在业务高峰执行：即使条件满足，也建议在低负载时段操作，防止瞬时 page fault 增加延迟。

执行命令（需 root）：

swapoff -a && swapon -a

配合 swappiness 调整降低复发风险

刷新 Swap 只是治标。若 swappiness 设置过高（如默认 60），内核会过早将冷页换出，加剧 Swap 波动。建议同步调低：

• 临时生效：sysctl vm.swappiness=10（值越低，越倾向保留数据在 RAM）；
• 永久生效：向 /etc/sysctl.conf 追加 vm.swappiness=10，再执行 sysctl -p；
• 注意：设为 0 不代表禁用 Swap，而是仅在内存真正耗尽时才使用，适合内存充裕的服务器。

后续必须跟进泄漏根因排查

Swap 刷新不能替代问题定位。内存泄漏会很快重现，必须立即启动排查：

• 对疑似进程，检查其 /proc/PID/smaps 中 RSS、SwapPss 和 MMUPageSize 字段变化趋势；
• Java 应用用 jstat -gc PID 观察老年代是否持续增长且 Full GC 无效；
• C/C++ 应用用 valgrind --tool=memcheck 或 gdb attach 后 dump heap；
• 检查内核 slab 泄漏：slabtop 看 dentry、inode_cache 等是否异常偏高（常见于 curl/NSS bug 或未关闭的 socket）。