先用cat /proc/PID/status | grep -i swap确认Swap字段是否大于0，再用smaps计算换出比例；若Swap为0，则卡顿与Swap无关；vm.swappiness=1比=0更稳，可避免OOM Killer误杀Redis。
怎么确认 Redis 正在被 Swap 换出
别急着关 Swap 或调 maxmemory，先看事实。Redis 卡顿 ≠ Swap 导致，很多抖动其实是 AOF rewrite、RDB fork、或 LFU 计数器衰减触发的内存重分配。真实 Swap 压力得靠进程级数据验证：
- 用
redis-cli info | grep process_id拿到 PID - 执行
cat /proc//status | grep -i swap，重点看Swap字段是否 > 0（不是SwapPss） - 再跑
cat /proc//smaps | awk '/^Size:/ {size+=$2} /^Swap:/ {swap+=$2} END {printf "Size: %d MB, Swap: %d MB\n", size/1024, swap/1024}'，看换出比例是否超过 10%
如果 Swap 始终为 0，说明卡顿跟 Swap 无关，调 vm.swappiness 或关 Swap 只会掩盖真问题。
直接 swapoff -a 的风险比你想象中大
关 Swap 看似一劳永逸，但 Linux 内核在物理内存彻底耗尽时，没有 Swap 缓冲区，OOM Killer 会立刻介入——而 Redis 进程因 RSS 高，大概率是第一个被杀的目标。这不是理论风险，生产环境已有多个案例：压测中 swapoff 后，maxmemory 尚未触顶，Redis 就被 Out of memory: Kill process redis-server 杀掉。
真正安全的做法是分两步：
- 先执行
swapoff -a，但必须同步在/etc/fstab中注释掉所有swap行，防止重启后自动启用 - 同时必须配
cgroups v2限制 Redis 内存上限，例如：echo 4G > /sys/fs/cgroup/redis/memory.max，这比依赖内核的 Swap 回收更可控
maxmemory 不设淘汰策略等于没设
只写 maxmemory 4gb 而不配 maxmemory-policy，Redis 默认用 noeviction。这意味着一旦内存超限，所有写命令直接返回 (error) OOM command not allowed when used memory > 'maxmemory'.——业务立刻报错，而不是平滑淘汰。
选策略要匹配业务语义：
- 缓存类数据（用户偏好、商品信息）：用
allkeys-lfu，配合lfu-log-factor 10和lfu-decay-time 1，避免冷 key 长期驻留 - 带明确过期时间的 session/token：改用
volatile-lru，但务必避免整数 TTL（如全部设 60s），否则会触发集中淘汰抖动 - 绝对不能用
volatile-ttl处理短生命周期 key，它在每 100ms 定期扫描 expires 字典，TTL 接近 0 的 key 越多，主线程阻塞越严重
为什么 vm.swappiness=1 比 =0 更稳
内核文档明确写清：vm.swappiness=0 并非禁用 Swap，而是“尽可能避免”。当匿名页（Redis 的堆内存）无法回收、且 zonefile + zonefree <= high_wmark_pages 时，仍会强制 Swap OUT。而设为 1，内核会优先回收 page cache（如文件缓存），给 Redis 留出更多干净物理页。
实测对比（CentOS 8 + Redis 7.2）：
-
swappiness=0：压测到内存使用率达 92% 时，Swap字段开始非零，延迟脉冲明显 -
swappiness=1：同样压测下，Swap保持为 0，PageOut次数上升但无延迟尖峰 - 关键点：必须搭配
maxmemory+ 合理淘汰策略，否则swappiness再低也挡不住 OOM
最易被忽略的是：Swap 抖动往往不是 Redis 单一进程的问题，而是它和 Java 应用、Logstash、Prometheus node_exporter 共享宿主机内存的结果。查 ps aux --sort=-%mem 比调参数更能定位根因。