Redis卡顿不一定由Swap引起，需先用cat /proc/PID/status | grep -i swap等命令确认Swap实际使用情况；vm.swappiness=0不等于禁用Swap，且可能引发OOM Killer；推荐设为1并配合maxmemory、cgroups等综合管控。
Redis卡顿是否真由Swap引起？先确认再动手
直接把 vm.swappiness 设为 0 不是万能解药，反而可能在内存不足时触发 OOM Killer 杀掉 Redis 进程。必须先验证 Swap 是否真在被使用：运行 cat /proc/<pid>/status | grep -i swap</pid>（<pid></pid> 换成 Redis 的实际进程号），看 Swap 字段是否大于 0；同时用 swapon --show 和 free -h 确认 Swap 分区是否启用、当前使用量。如果 Swap 值始终为 0，卡顿跟 Swap 无关，别动 vm.swappiness。
为什么 vm.swappiness=0 并不等于“禁用 Swap”
Linux 内核文档明确说明：vm.swappiness=0 仅表示“尽可能避免 Swap”，但以下情况仍会交换：
- 内存严重不足且有匿名页（如 Redis 的堆内存）无法回收时，内核仍可能换出部分页
- 系统启用了
zram或zswap，它们绕过传统 Swap 逻辑，swappiness对其无效 - 某些发行版（如 RHEL 8+）默认启用
memory.mincgroup 限制，会干扰 swappiness 行为
真正想禁用 Swap，得先执行 swapoff -a，并注释或删除 /etc/fstab 中的 swap 行。仅调 vm.swappiness 是治标不治本。
Redis 场景下更有效的内存控制组合
单纯压低 vm.swappiness 效果有限，应配合以下措施：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在 Redis 配置中显式设置
maxmemory，并选合适策略（如maxmemory-policy allkeys-lru），防止内存无限增长 - 用
cgroups v2限制 Redis 进程组内存上限（如memory.max），比内核参数更精准 - 检查是否有其他进程与 Redis 争抢内存（
ps aux --sort=-%mem | head -10），尤其是 Java 或 Python 后台服务 - 确认 Redis 是否启用了
activedefrag，碎片整理本身会增加内存压力，可能间接诱发 Swap
这些操作比全局改 vm.swappiness 更安全、更可预测。
vm.swappiness=1 比 =0 更适合生产 Redis 实例
内核开发者多次指出：swappiness=0 在现代内存管理中过于激进，容易导致 page cache 回收失衡，反而加剧 I/O 延迟。对 Redis 这类内存敏感服务，vm.swappiness=1 是更稳妥的选择：
- 它允许内核在极端压力下换出极少量匿名页，避免 OOM Killer 突然介入
- 保留 page cache 的弹性，有利于 AOF 重写或 RDB 生成时的文件读写性能
- 多数云厂商（AWS EC2、阿里云 ECS）默认值就是 1，而非 0
修改后需执行 sysctl -w vm.swappiness=1 并写入 /etc/sysctl.conf 持久化。别迷信“0 就是最优”，真实系统里边界条件远比想象中多。
