Redis集群绝不能运行在启用Swap的机器上，否则会导致毫秒级延迟突增、连接超时、主从失联等确定性故障；需通过cat /proc//smaps | egrep '^(Size|Swap)'确认内存换出情况，并用swapon --show验证Swap状态，立即执行swapoff -a禁用。
Redis因Swap开启导致淘汰变慢，必须关掉
Swap不是“备用内存”，而是性能灾难的开关。Redis进程一旦被OS换出到磁盘，freeMemoryIfNeeded函数在淘汰key时会频繁触发缺页中断，单次淘汰可能从毫秒级拖到几百毫秒甚至秒级——这不是策略问题，是I/O阻塞。你调大maxmemory-samples或切到allkeys-random都救不回来。
- 立刻检查：
cat /proc/<pid>/status | grep -i swap</pid>，看Swap字段是否非零 - 确认系统Swap启用状态：
swapon --show；若输出非空，说明Swap已激活 - 临时禁用（重启前有效）：
sudo swapoff -a - 永久禁用：注释或删除
/etc/fstab中含swap的行，再执行sudo systemctl daemon-reload
为什么Redis对Swap特别敏感？
Redis是单线程事件循环模型，所有操作（包括淘汰、过期key清理、AOF重写）都在主线程同步执行。当内存页被Swap出去，主线程访问这些页时会卡住等待磁盘读入，整个实例就“假死”。而其他服务（如MySQL）多线程+预读机制还能缓冲，Redis没有这个余量。
- 哪怕只有1%的Redis内存被Swap，也可能让
DEL一个bigkey耗时从20ms飙到2s+ -
INFO memory里mem_fragmentation_ratio可能正常（比如1.05），但used_memory_rss远高于used_memory，这是Swap正在发生的典型信号 - Linux内核参数
vm.swappiness=0不能替代swapoff，它只降低倾向，不阻止Swap发生
关Swap后还要防OOM Killer误杀
Swap关了，物理内存又吃紧时，Linux可能直接kill掉Redis进程。这不是淘汰慢，是进程没了。
- 务必设置
vm.overcommit_memory=1（允许内存过度分配，避免alloc失败） - 给Redis进程加
oom_score_adj=-1000（彻底禁止OOM Killer选中它）：echo -1000 > /proc/<pid>/oom_score_adj</pid> - 配合
maxmemory硬限制使用，例如设为物理内存的75%，留出系统缓存和Redis自身开销余量
别信“Swap只是兜底”这种说法
生产环境里，Swap从来不是兜底，它是雪崩的引信。你看到CONFIG GET maxmemory-policy返回allkeys-lru，以为淘汰逻辑在跑，其实主线程正卡在磁盘IO上等一页内存回来。这时候redis-cli --latency测出来的延迟会毫无规律地尖刺式飙升，SLOWLOG里全是del、evict类命令超时——这些都不是Redis的问题，是OS在背后拖后腿。
