Redis延迟抖动？从内核到应用层的Ubuntu系统调优全攻略

缓存服务跑了一段时间，Redis 自身的吞吐指标看起来还过得去，但用户体验总是差那么一点。尤其到了晚高峰，客户端偶尔蹦出几百毫秒的超时，一看延迟分布，p99 已经悄悄从平时的 1ms 涨到 8ms，甚至更高。最开始怀疑慢查询、大 key、热点 key 这些老问题，排查一圈下来，Redis 侧能优化的都优化了，瓶颈依然卡在那里。最后我才反应过来：真正的天花板根本不在 Redis 进程内部，而在 Ubuntu 20.04 服务器这一层——内核参数、内存管理、网络协议栈、CPU 调度和磁盘 I/O，任何一环掉链子，都能把 Redis 的响应速度按在地上摩擦。

这篇文章，我把当时从内核层到应用层完整做过的系统调优过程整理出来。内容包括透明大页、NUMA、内存预算、TCP backlog、TIME_WAIT 复用、CPU 绑核、I/O 调度、脏页刷盘参数，以及 Redis 自身配置如何配合系统参数一起生效，最后附上压测数据和排障实录。适合正在用 Redis 做缓存、遇到延迟抖动，或者想在现有机器上再榨出一些性能的运维和开发同学参考。

1. 先想清楚：系统瓶颈到底在哪一层

1.1 为什么 Redis 配置优化解决不了所有问题

很多人在优化 Redis 时会陷入一个误区：把注意力全放在 Redis 的配置上，比如调 maxmemory、换淘汰策略、改持久化方式，觉得只要 Redis 进程内部够高效，整体性能就一定好。

但实际上，一个客户端的 GET 请求从进入到返回，走的完整链路是：网卡收包，内核协议栈解析 TCP，放入 socket 接收队列，Redis 事件循环从队列中读取数据，解析命令，访问内存，构造回复，再经由内核协议栈发出去。这一整条链路上，任何一个环节阻塞，哪怕 Redis 进程内部再快，客户端感受到的依然是延迟。

举两个典型例子。你在 redis.conf 里把 tcp-backlog 设成 1024，但内核的 net.core.somaxconn 还是默认的 128，那么当并发连接超过 128 时，多余的连接握手请求会被内核直接丢弃，客户端表现为 Connection Refused。再比如你把 maxmemory 设置得很满，系统默认 vm.overcommit_memory=0，Redis 在做后台持久化的 fork 操作时，内核基于启发式判断可能直接拒绝分配内存，导致 fork 失败、持久化任务被中断。

这些都不是 Redis 进程内部能解决的，必须回到操作系统层。系统调优的意义，就是把这整条链路中的隐藏瓶颈逐个排除掉，让 Redis 的性能真正发挥到硬件允许的上限。

1.2 一次线上 Redis 延迟抖动，如何一步步定位到系统层

之前我负责的一个业务，Redis 实例规格是 16 核 32G 内存，缓存命中率一直很健康，CPU 使用率也只有 20% 到 30%，网络带宽远没到上限。但就是会周期性出现客户端超时，高峰期尤其明显。

第一轮排查从 Redis 自身入手：SLOWLOG 里没有特别慢的命令，INFO commandstats 也没有异常偏高的命令，大 key 扫描也没发现可疑对象。这就说明问题不在 Redis 命令执行层面。

第二轮看系统和网络。用 redis-cli --latency 监控实时延迟，发现周期性的 spikes；打开 vmstat 1 盯着 si 和 so 两列，竟然能看到换入换出，top 里 kswapd0 进程时不时在跑。真相大白了：一台专门跑 Redis 的服务器，竟然在 swap。Redis 的某些内存页被内核换到磁盘上，访问这些页时触发缺页中断，进程被挂起，表现出来就是客户端延迟瞬间飙升。

这个案例让我彻底明白一件事：当 Redis 配置已经合理时，性能波动往往来自操作系统层面。内存换页、中断处理、CPU 抢占、TCP 队列溢出，每一项都是隐蔽的延迟源。后面我做的所有调优，都是围绕"让系统为 Redis 让路"这个思路展开的。

2. 内存层调优：决定 Redis 生命线的三项操作

2.1 关闭透明大页：最立竿见影的一步

透明大页（Transparent Huge Pages，THP）是 Linux 内核的默认特性，它会把 4KB 小页自动合并成 2MB 大页，目的是减少 TLB miss，理论上能提升内存密集型应用的性能。听着很不错，但对 Redis 来说，THP 是性能杀手。

原因在于 Redis 依赖 fork 机制做持久化。当 Redis 执行 BGSAVE 或 AOF rewrite 时，主进程会 fork 出一个子进程来写数据，子进程和父进程共享同一份物理内存，采用写时复制（COW）策略。问题是，内存页越大，进程页表数量虽然少了，但 COW 的粒度也变大了。原本只需要复制一个 4KB 小页就能完成的写入，在 THP 开启时可能要复制整个 2MB 大页，这让 fork 期间的复制成本成倍增长，主进程阻塞时间明显拉长。Redis 官方文档和源码注释里很早就强调了这一点。

关闭 THP 的操作很简单，临时生效的命令是：

bash复制echo never > /sys/kernel/mm/transparent_hugepage/enabled

但 Ubuntu 20.04 服务器重启之后大概率会恢复默认，所以最好做成一个 systemd 服务，确保每次开机自动关闭。我习惯这样写：

bash复制sudo tee /etc/systemd/system/disable-thp.service <<'EOF'
[Unit]
Description=Disable Transparent Huge Pages (THP)
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now disable-thp.service

验证是否生效，直接看文件内容，方括号所在位置就是当前启用的策略：

bash复制cat /sys/kernel/mm/transparent_hugepage/enabled
# 输出：always madvise [never]

这一步做完，很多 Redis 实例的 latest_fork_usec 会从几百毫秒掉到几十毫秒级别，是整套调优里性价比最高的一项。

2.2 让 Redis 留在正确的 NUMA 节点上

NUMA（非统一内存访问架构）是多路服务器上的一个重要概念。在多 CPU 插槽的机器上，每个 CPU 访问自己直连的内存速度快，访问远端 CPU 直连的内存速度慢。如果 Redis 进程的线程今天调度在 node 0，明天调度到 node 1，内存又分布在不同的 NUMA 节点上，跨节点访问的开销会直接反映在延迟上。

先用 numactl --hardware 查看服务器拓扑，确认有几个 NUMA 节点，各节点分配了多少内存。对于一台专门跑 Redis 的服务器，最简单的思路是把 Redis 进程和它的内存全部固定在同一个 NUMA 节点上，避免跨节点访问：

bash复制numactl --cpunodebind=0 --membind=0 redis-server /etc/redis/redis.conf

如果 Redis 实例分布在不同 NUMA 节点上，或者多个 Redis 实例同时跑在同一台机器上，可以考虑交错分配模式，让内存均匀分布：

bash复制numactl --interleave=all redis-server /etc/redis/redis.conf

有一点必须提醒：NUMA 绑定不是无脑操作。如果绑定了 node 0，但网络中断和高频工作线程都被调度到 node 1，反而会制造更多的跨节点通信。在没有压测对比的情况下，不要盲改。云服务器上的行为也会因虚拟化层不同而有差异，最好用 numactl --hardware 和压测工具实测后再定。

在 Redis 6.0 及以上版本中，CPU 亲和也可以通过配置项直接管理，比如 server_cpulist、bio_cpulist、bgsave_cpulist，让主线程、后台 I/O、持久化子进程各跑各的核，比单纯依赖 taskset 更精细。不过这些属于进阶玩法，基础场景先把 NUMA 节点对齐就够了。

2.3 内存预算、overcommit 和 swap 的配合

Redis 是内存型应用，内存策略的每一个决定都直接影响稳定性和响应速度。三个核心点：swappiness、overcommit、内存余量。

先看 vm.swappiness。Ubuntu 默认值是 60，意味着内核在回收内存时会相当积极地使用 swap 空间。对 Redis 这种常驻大型数据集的应用，一旦发生换页，延迟抖动立刻出现。官方文档建议设置为 0，但我更推荐 1，既避免主动换出 Redis 的匿名内存页，又保留了极端内存压力下的最后防线。设置方法写在 /etc/sysctl.d/99-redis-tuning.conf 里：

conf复制vm.swappiness = 1
vm.overcommit_memory = 1

再看 vm.overcommit_memory。内核默认是 0，表示启发式 overcommit，即根据当前内存状态判断是否允许超额分配。问题在于 Redis fork 子进程时，即便子进程最终没有写太多内存，内核也可能基于保守评估拒绝分配，导致 BGSAVE 失败。设置成 1 后，内核不再做这种检查，fork 的失败率大幅降低。

但 overcommit=1 不是免死金牌，它只是绕过了内核检查。真正扛住内存压力的是你给系统留了多少余量。假如一台 32G 的服务器跑 Redis，数据集实际占用 20G，如果 maxmemory 设成 28G，一旦触发 BGSAVE，写时复制的内存开销叠加上去，物理内存瞬间被吃满，接下来不是 swap 就是被 OOM Killer 点名。

一个相对安全的内存预算公式，我一般按这个思路算：maxmemory 不要超过物理内存的 60% 到 70%，剩下的空间留给操作系统、客户端缓冲区、复制积压缓冲区、AOF rewrite 或 BGSAVE 的 COW 开销。比如 32G 物理内存，我会把 Redis 的 maxmemory 设置在 20G 到 22G 左右，实际运行中再把 INFO memory 里的 used_memory 和 used_memory_rss 对照看，确保 RSS 没有逼近物理内存上限。

3. 网络层调优：把 TCP 队列和连接生命周期理顺

3.1 somaxconn 与 tcp-backlog：监听队列的匹配是关键

Redis 的 tcp-backlog 参数默认是 511，控制的是监听 socket 的 accept 队列长度。但 Linux 内核还有一个独立参数 net.core.somaxconn，它限制所有 socket 的 accept 队列上限，默认只有 128。两边不匹配时，Redis 启动日志会直接打警告：

text复制WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

后果是什么？当客户端短连接突发、连接请求超过 128 时，内核直接丢弃多余的 SYN 请求，客户端重试无果，现象就是间歇性的 Connection Refused 或超时。对 Redis 这种需要快速响应大量连接的场景，这是致命的。

修改方式很简单，在 /etc/sysctl.d/99-redis-tuning.conf 里加：

conf复制net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 1024

然后加载配置：

bash复制sudo sysctl --system
# 或者指定文件加载
sudo sysctl -p /etc/sysctl.d/99-redis-tuning.conf

同时把 redis.conf 里的 tcp-backlog 改成 1024，保持两边一致。这个 Redis 参数改了之后需要重启实例才能真正对监听 socket 生效，因为运行期的 CONFIG SET 不会重新创建监听 socket。重启前先确认业务连接有重连机制，避免明明在优化，反而制造一次可感知的抖动。

验证是否生效，用 ss -lnt 看监听队列有没有堆积：

bash复制ss -lnt sport = :6379
# 观察 Recv-Q 列

Recv-Q 如果长期不为 0，说明 accept 队列有堆积，内核和 Redis 的 backlog 还需要继续加大。

3.2 端口范围与 TIME_WAIT：高并发连接下的两类问题

除了监听队列，高并发下的两个经典网络问题分别是本地端口耗尽和 TIME_WAIT 堆积。

当客户端使用短连接访问 Redis 时，每次连接都会占用一个临时的本地端口。Linux 默认的临时端口范围比较窄，大概是 32768 到 60999，大约两万多个。如果短连接速率非常高，端口很容易被占满，新连接直接失败。解决方法是把端口范围扩大：

conf复制net.ipv4.ip_local_port_range = 1024 65535

这个参数主要作用于出站连接。Redis 作为服务端时，客户端侧如果要减少 TIME_WAIT，可以在应用服务器的内核参数里开启 net.ipv4.tcp_tw_reuse = 1，让内核在需要时复用处于 TIME_WAIT 的连接资源。注意，这里说的是出站连接复用，对监听端口上的 TIME_WAIT 无效。tcp_tw_reuse 在 Linux 4.12 之后的内核里是安全且推荐的，但我们不会去碰另一个已经失效的 tcp_tw_recycle 参数，那个参数在 4.12 之后被移除了，写了也没用。

如果 Redis 实例之间也需要通信，比如主从复制、集群节点间握手，Redis 自己也会以客户端身份发起连接，这时把 tw_reuse 放在 Redis 所在服务器上是合理的。同时可以适当缩短 FIN 等待时间：

conf复制net.ipv4.tcp_fin_timeout = 15

最终形态的配置大概是：

conf复制net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

这里要泼一盆冷水：内核参数只能缓解问题，不能根治问题。如果应用层是高频短连接访问 Redis，再多的端口也不够折腾，正确的做法是把客户端连接池化，用连接池复用长连接。系统调优是给架构兜底，不是让架构偷懒。

3.3 内核缓冲区：什么时候值得调大，什么时候不要动

net.core.rmem_max、net.core.wmem_max，以及 TCP 层次对应的 net.ipv4.tcp_rmem 和 net.ipv4.tcp_wmem，是另外一组容易让人冤枉调大的参数。

先说结论：如果 Redis 缓存的主要是几百字节的小 value，默认的 socket 缓冲区完全够用，没必要调大。乱调大缓冲区反而会让每个连接占用的内核内存上升，高并发时白白消耗内存资源。

但如果业务里有大量 MB 级别的对象，比如缓存了图片裁剪结果、序列化后的业务实体，默认缓冲区会成为发送瓶颈。发送缓冲区过小时，内核会频繁触发消息碎片化和一次 TCP 段只能装一半数据的尴尬状态，拉高 CPU 使用率，延迟也会上去。

需要调大时的配置参考：

conf复制net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216

但注意，调大之后一定要监控内存变化。内核缓冲区是每个连接独立分配的，连接数一多，内存消耗是线性增长。我的习惯是先确认线上有没有大 value 场景，没有就保持默认；有则先优化数据设计，把大对象拆小，能不动内核缓冲区就不动。

4. 调度与存储层调优：让 CPU 和磁盘都别拖后腿

4.1 CPU 绑核与上下文切换控制

在单核时代，进程调度很纯粹，谁抢到 CPU 谁干活。但现代服务器动辄十几甚至几十个逻辑核，Redis 虽然是单线程模型，它的子进程、后台线程和网络中断处理却可能在不同核之间跳来跳去，每次迁移都会带来缓存失效和上下文切换开销。

先用 pidstat 观察上下文切换情况：

bash复制pidstat -w 1

如果看到非自愿上下文切换（cswch/s）很高，说明 Redis 线程经常被其他进程抢占。这种情况下，把 Redis 主进程绑到一组固定的 CPU 核上，可以显著减少迁移开销。Ubuntu 下用 taskset 即可：

bash复制taskset -pc 0-3 <redis_pid>

或者在启动时直接绑定：

bash复制taskset -c 0-3 redis-server /etc/redis/redis.conf

绑核要注意拓扑。用 lscpu -e 查看每个 CPU 号对应的物理核和逻辑核，尽量绑在同一个 NUMA 节点上的连续物理核。如果绑定的是超线程的两个逻辑核，它们共享同一份执行资源，Redis 反而可能和别的线程抢资源，得不偿失。

Redis 6.0 之后还提供了更精细的 CPU 亲和配置。比如在主线程、bio 线程、后台保存线程之间做隔离：

conf复制server_cpulist 0-3
bio_cpulist 4-5
bgsave_cpulist 6-7

这样 RDB 持久化和 AOF rewrite 就不至于和主线程抢占相同的 CPU 核心。配置后记得重启实例并观察 INFO cpu 里的进程 CPU 消耗是否有变化。

额外提一句 irqbalance。Ubuntu 默认启用了 irqbalance 服务，负责把硬件中断分发到多个 CPU 上。对大多数云服务器，保持默认就行。真要追求极致，可以把网卡中断绑定到 Redis 所在的 NUMA 节点，但操作复杂，而且云虚拟化环境下收益不稳定。我建议先做绑核，中断亲核属于"最后 1%"的优化，没有充分压测前别折腾。

4.2 I/O 调度器与脏页刷盘参数

Redis 虽然以内存操作闻名，但持久化一旦发生，磁盘 I/O 就会成为不可忽视的因素。Linux 内核的 I/O 调度器在不同硬件上有不同的最优解。

传统 HDD 时代默认用 deadline 或 cfq，主要为了减少磁盘寻道时间。现代 SSD 尤其是 NVMe 云硬盘，寻道时间几乎可以忽略，队列多反而更有利。查询当前调度器：

bash复制cat /sys/block/vda/queue/scheduler

输出可能是 [none] mq-deadline 或 [mq-deadline] none。方括号代表当前启用的调度器。对 SSD 云盘我一般推荐使用 none，也就是 noop，让硬件自身的多队列机制去处理请求。临时修改：

bash复制echo none > /sys/block/vda/queue/scheduler

要持久化，写一条 udev 规则。下面以 vda 为例：

bash复制sudo tee /etc/udev/rules.d/60-io-scheduler.rules <<'EOF'
ACTION=="add|change", KERNEL=="vda", ATTR{queue/scheduler}="none"
EOF

除了调度器，脏页刷盘参数也值得关注。所谓脏页，就是内存中被修改过但还没写回磁盘的页。Linux 会在内存中累积脏页，等比例或时间到达阈值后再统一刷出。参数默认 vm.dirty_background_ratio=10 和 vm.dirty_ratio=20，分别表示脏页占可用内存 10% 时启动后台刷盘，占 20% 时进程的写操作会被强制同步阻塞。

Redis 在做 BGSAVE 或 AOF rewrite 时会大量写入文件，如果脏页比例过高，突发的强制刷盘会让写进程卡住，间接拖慢 Redis 主进程。把阈值调低一点，让刷盘工作平滑进行：

conf复制vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

这两个参数同样可以在 /etc/sysctl.d/99-redis-tuning.conf 里配置。调低之后磁盘写入会分散到更长时间里完成，对延迟更友好。

4.3 持久化落盘策略与系统参数的协同

系统层的 dirty 参数决定了内核刷盘节奏，但 Redis 落盘策略决定了它给内核制造多少写入压力。两者必须配合。

首要问题是避免频繁的 BGSAVE。默认配置下 Redis 可能根据 save 点自动触发快照，比如 60 秒内写入了 1 万个 key。但在大内存实例上，每次 BGSAVE 的 fork 操作都会短暂冻结主线程，块越大冻结越明显。缓存场景其实很多是可以接受丢失少量数据的，关闭 RDB 自动快照，只保留 AOF 是常见做法：

conf复制save ""
appendonly yes
appendfsync everysec

appendfsync everysec 是大多数场景的最佳选择。always 级别每个命令都 fsync，延迟和写放大都很大；关闭 fsync 则最多丢很多秒的数据，对业务不可接受。everysec 在性能和可靠性之间取了平衡，Redis 主进程每秒最多被 fsync 阻塞一次，通常这个阻塞在毫秒级别。

AOF rewrite 期间还有另一个重要参数：

conf复制no-appendfsync-on-rewrite yes

rewrite 本质上是在后台把内存中的数据集整理成新的 AOF 文件，期间会有大量磁盘写入。如果此时主进程还坚持每秒 fsync，两者抢磁盘 I/O，主进程可能会被 fsync 阻塞拖死。设置成 yes，让 rewrite 期间跳过 fsync，虽然可能多丢 1 秒数据，但主进程的响应稳定性保住了。

最后确认 aof-use-rdb-preamble yes，这样 AOF 文件头部用 RDB 格式存储当前数据集快照，后续只追加增量命令，加载速度和文件体积都比纯 AOF 更优。在 Redis 5.0 及以上版本，这个选项默认开启，但手工确认一下不会有坏处。

5. Redis 自身的配合参数：系统调优不是单方面的事

5.1 需要和内核参数对齐的几个 Redis 配置

内核参数是地基，Redis 配置是房子，两边必须对齐。不匹配的配置，再好的内核参数也会被 Redis 侧悄悄抵消。

第一个是 tcp-backlog，上一节已经说过，redis.conf 里要设成和内核 somaxconn 匹配的值：

conf复制tcp-backlog 1024

第二个是 maxmemory 和 maxmemory-policy。在缓存场景下，我一般配置：

conf复制maxmemory 20gb
maxmemory-policy allkeys-lru
maxmemory-samples 10

allkeys-lru 是在所有 key 里做 LRU 淘汰，适合缓存。maxmemory-samples 默认是 5，适当提高到 10 可以让淘汰精度更高一点，代价是 CPU 消耗略增。对 Redis 这种单线程模型，CPU 很宝贵，如果实例 QPS 本来就高，samples 保持 5 也没问题。

第三个是连接数相关的参数。maxclients 默认 10000，看起来够大，但前提是系统文件描述符上限也够大。Ubuntu 自带的 redis 服务通过 systemd 管理，如果日志里频繁出现 Can't handle many clients，用下面的命令检查：

bash复制ulimit -n

需要提高限制时，在 /etc/systemd/system/redis.service.d/override.conf 里写：

conf复制[Service]
LimitNOFILE=65535

然后重载 systemd 并确认 Redis 进程的实际限制：

bash复制sudo systemctl daemon-reload
sudo systemctl restart redis
cat /proc/$(pidof redis-server)/limits | grep "open files"

第四个是慢日志和延迟监控的阈值，这部分其实属于"可观测性调优"，让问题更容易暴露。默认的 slowlog-log-slower-than 是 10000 微秒，也就是 10ms，太迟钝了。在缓存场景下，超过 1ms 的命令就应该被记录：

conf复制slowlog-log-slower-than 1000
slowlog-max-len 128
latency-monitor-threshold 100

把这些阈值调低之后，再配合内核参数优化，排查延迟抖动时会有更多有效数据可用。

5.2 用 INFO、SLOWLOG 和 latency 验证系统调优效果

调优不是改完参数就完事，必须有一整套验证手段来确认效果。我常用的四个命令：

第一个是 redis-cli --latency，用来观察从当前机器到 Redis 的网络延迟分布：

bash复制redis-cli --latency -h 127.0.0.1 -p 6379

它会持续输出 min、avg、max 三个延迟值。如果 max 值忽大忽小，说明延迟不稳定，系统层还有问题。

第二个是 redis-cli --intrinsic-latency，它测试的是 Redis 所在机器内部线程调度的延迟，不经过网络，用来判断瓶颈在进程内还是网络链路上：

bash复制redis-cli --intrinsic-latency 100

第三步看 INFO stats 里的 latest_fork_usec，这个值记录了最近一次 fork 消耗的微秒数。如果关闭 THP 前后，这个值从几十万微秒降到几万微秒，说明调优有效。

第四步看 SLOWLOG GET。调低慢日志阈值后，定期查看哪些命令超过阈值。比如：

bash复制redis-cli slowlog get 50

如果在慢日志里反复看到 KEYS 或 SMEMBERS，那是命令选择问题，和系统调优无关；如果看到的是 GET、SET 这种简单命令也超时，那就要回到系统层继续排查。

另外要养成看 INFO commandstats 的习惯，它按命令统计了调用次数和总耗时，可以直观看出哪些命令贡献了大部分延迟。把这些数据和压测工具的结果放在一起，才能判断调优到底打在哪个点上。

6. 压测验证：调优到底带来了多少提升

6.1 压测环境与基准方法

调优这套东西，不做压测等于白做。我当时的测试环境是 4 核 8G 内存的云服务器，Ubuntu 20.04，内核 5.4，Redis 6.0.16 单实例，数据量约 100 万 key，value 设置为 128 字节，测试工具用 redis-benchmark。

需要重点关注的是，压测命令要模拟真实业务，不能只打单一命令。下面一组参数比较常用：

bash复制redis-benchmark -h 127.0.0.1 -p 6379 -t set,get -n 1000000 -c 50 -P 16 -r 1000000 -d 128 --threads 4

解释几个关键参数：-t set,get 指定测试命令；-c 50 是 50 个并发连接；-P 16 是开启 16 条流水线；-r 1000000 让键名在 100 万范围内随机取值，避免所有请求打在同一个 key 上；-d 128 表示 value 大小 128 字节；--threads 4 是 redis-benchmark 自身用 4 个线程。

压测时长要够，我一般让测试持续 5 到 10 分钟，只跑 10 秒很容易错过 fork 或者内存回收造成的偶发抖动。

除了 redis-benchmark，我还会同步跑 redis-cli --latency 观察请求延迟分布。两个工具互相印证，别只看一个数据。

6.2 调优前后数据对比与解读

以下是我在测试机上记录到的一组前后对比数据，注意不同机器差别会很大，但这个量级变化很典型：

QPS 提升约 40% 到 50%，平均延迟降到原来的约五分之一，更关键的是 p99 和 p999 这种长尾延迟被压缩下来了。长尾延迟直接影响用户体验，很多线上超时就是 p999 引起的，能把 p999 从 22ms 压到 3.5ms，效果非常直观。

不过要提醒一点：-P 16 表示开启了流水线，单次请求的 RTT 被分摊到 16 条命令上，这里的平均延迟是聚合后的表现。如果想看真实的单请求延迟，要用 -P 1 再测一轮，或者在压测时单独记录 redis-cli --latency 的输出。实际业务中如果客户端没有开流水线，不能用 -P 16 的结果作为绝对参考，但调优前后的相对变化是有意义的。

还有一个容易忽略的指标：调优后的延迟稳定性。调优前压测过程中 QPS 曲线会时不时掉几个深坑，对应的是 kswapd 回收页面或者 THP 的分配毛刺；调优后曲线明显平滑很多。对生产环境来说，稳定的低延迟比偶尔爆发的高速更有价值。

7. 常见问题与排查技巧实录

7.1 高频问题速查表

这几年折腾 Redis 系统调优，遇到过不少典型问题，整理成一张速查表，遇到类似情况可以直接对着查：

最后一行的大 value 问题，严格说不是系统调优能解决的。Redis 单线程模型下，复制几 MB 的 value 本身就会阻塞主线程。内核参数改得再激进，也挡不住一次 O(n) 复制造成的秒级卡顿。这属于缓存治理范畴，和系统调优是两套手段，但实际排查时经常混在一起出现，需要联动解决。

7.2 几次排障后我最想说的经验

踩过几轮坑之后，我最想分享的是这三条经验。

第一条，内核参数不是越大越好。每一项参数背后都有内存、CPU 或连接管理上的成本。somaxconn 调得过大，大量空闲连接堆在队列里，白白占用内存；socket 缓冲区调得过大，高并发时每连接多出几十 KB 的内存消耗，乘以几万个连接就是几个 G。调优的原则是"够用且留一点余量"，不是"最大即最好"。

第二条，每次只改一组参数，验证后再动下一组。我见过很多人把网上的参数一次性全部贴进去，改完不知道是哪个起了作用，出了问题也不知道是哪个引入的。正确做法是：先压测一轮拿到基线，改一项，压测一轮，记录数据，再改下一项。虽然费时间，但出了问题可以精确定位，线上环境尤其要这样。

第三条，云服务器加上系统调优之前，先确认同类实例的表现是否稳定。虚拟化环境下，邻居实例的 CPU 抢占、宿主机磁盘 I/O 波动都可能压制性能。有时候你熬夜调了一整晚内核参数，第二天发现效果有限，其实是宿主机层面的干扰。遇到这种情况别死磕，先换个时段或实例规格做对照组，再决定要不要继续深入。

最后再分享一个细节：关闭 THP 的 systemd 服务，我见过多台机器因为换过系统盘或做镜像恢复后，服务单元没被正确 enable，导致 THP 重启后又恢复开启。每次服务器重启后，把检查 THP 状态加进例行巡检脚本里，不然你在性能优化上做的努力，可能早就悄悄失效了。