卡顿不一定由swap引起，需先用free -h、cat /proc/swaps、cat /proc/pid/status | grep -i swap等命令确认swap实际使用情况；vm.swappiness=0不等于禁用swap，可能引发oom killer，推荐设为1并配合maxmemory、cgroups等综合管控。
卡顿真由交换分区引起？别急着调参数，先确认再动手。
第一步：确认 Swap 是否真在拖慢系统
物理内存还有余量，但系统卡得动不了——这很可能是 Swap 在“假勤奋”。用三步快速验证：
- 运行 free -h，重点看 Swap 行的 used 值。如果非零（比如 1.2G/2G），说明 Swap 正被使用；
- 执行 cat /proc/swaps，确认是否启用了 Swap 文件或分区，以及优先级（priority）；
- 查具体进程：用 cat /proc/$(pgrep redis)/status | grep -i swap（把
redis换成你的服务名），看Swap字段是否大于 0 —— 若为 0，卡顿和 Swap 无关，别碰vm.swappiness。
第二步：看内核是否在“过度换页”
swap 使用量不高，但 si（swap-in）和 so（swap-out）持续不为 0，说明系统正频繁换页，I/O 已成瓶颈：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 运行 vmstat 1 10，观察
si和so列：每秒都有几十 KB 以上读写，就是异常信号； - 配合 iostat -x 1 看
%util和await：若磁盘利用率长期 >80% 或 await >50ms，Swap I/O 正在拖垮响应速度； - 检查 dmesg | grep -i "out of memory\|oom"，有 OOM 记录说明内存已到临界，Swap 不是主因而是结果。
第三步：检查 swappiness 设置是否合理
vm.swappiness=0 并不等于禁用 Swap，反而可能让内核在内存吃紧时突然触发 OOM Killer 杀掉关键进程：
- 查当前值：cat /proc/sys/vm/swappiness；
- Redis、MySQL 等内存敏感服务，推荐设为 1（不是 0），它允许极端压力下换出极少量匿名页，避免 OOM，同时保留 page cache 弹性；
- 临时生效：sysctl -w vm.swappiness=1；永久生效：写入
/etc/sysctl.conf并执行sysctl -p； - 真正禁用 Swap 要执行 swapoff -a，并注释
/etc/fstab中 swap 行 —— 仅调参数没用。
第四步：结合其他内存策略协同控制
单靠调 swappiness 治标不治本。更有效的组合是：
- 给 Redis 配 maxmemory + 合理淘汰策略（如
allkeys-lru），防止无节制占用； - 用 cgroups v2 限制进程组内存上限，比全局参数更精准；
- 检查 Redis 是否开了
activedefrag：碎片整理会临时放大内存压力，可能间接诱发 Swap； - 确认是否有其他服务（如 Java 应用）未设堆内存上限，悄悄吃掉大量 RAM。
