Swap频繁使用不等于系统故障，而是内存不足的警示；需检查available值、Inactive(anon)页及进程Swap占用，优化swappiness、应用内存配置并结合扩容与监控闭环治理。
Swap频繁使用，不等于系统坏了，但确实说明内存管理正在“负重前行”。关键不是禁用Swap，而是搞清它为什么被反复调用，再针对性优化。
物理内存长期吃紧是主因
哪怕swappiness=10，只要应用常驻内存接近物理上限，内核就只能把冷匿名页（比如Java堆里长期未访问的对象、数据库缓存中闲置的页）换出。这不是参数失灵，是内存真的不够用了。
- 检查
free -h中的available值，而非简单看used；若available持续低于1GB，压力已实质存在 - 用
cat /proc/meminfo | grep -E "Active\(anon\)|Inactive\(anon\)"确认Inactive(anon)是否偏高——这是Swap主力来源 - 典型表现：top里某个进程RSS不大，但Swap占用几百MB（如宝塔BT-Task、未调优的Java服务）
Swappiness只是倾向，不是开关
设为10，只代表内核更愿意回收page cache，而不是匿名页；但它从不承诺“绝不swap”。当page cache也释放不出足够空间时，匿名页照换不误。
- 不要盲目设为0：0会禁用swap for anonymous pages，但可能引发OOM Killer杀进程，风险更高
- 数据库、实时服务建议设为1；通用服务器10较稳妥；仅在内存远超负载且明确禁用休眠时才考虑0
- 修改后需配合
sudo sysctl -p生效，别只改配置不加载
应用层行为放大Swap压力
很多Swap问题根源不在系统，而在程序怎么用内存。预分配、不释放、压缩失败、大页整块换出，都会让swap停不下来。
- Java应用避免
-Xmx设得过大又长期低活跃，可加-XX:+AlwaysPreTouch或启用ZGC减少冷页 - Redis/Kafka等服务，确认是否启用
transparent_hugepage=never，防止2MB大页被整体swap - 若用zswap，检查
cat /sys/module/zswap/parameters/compress_failures，失败率高说明数据难压缩，实际仍落盘swap
临时缓解与长期治理并行
排查清楚后，操作要分层次：紧急止血靠清理和限流，根本解决靠扩容和调优。
- 临时释放：执行
echo 1 | sudo tee /proc/sys/vm/drop_caches清page cache（安全），慎用echo 3 - 限制失控进程：
systemctl set-property [service].service MemoryMax=4G（cgroup v2环境） - 扩容更直接：加内存比调参数见效快；Swap文件可临时扩（如
dd if=/dev/zero of=/swap2 bs=1G count=4），但不能替代RAM - 监控闭环：用
vmstat 1盯住si/so；搭配smem -s swap -r | head -5定位真凶进程
