38. 性能监控与基准测试

「码上学」常说：看不见，就无从优化。Redis 跑得快，但一旦慢下来，你要能立刻定位是内存吃紧、命令太重，还是网络延迟。本章给你三件武器：INFO 看运行全貌、redis-benchmark 测极限吞吐、慢日志（SLOWLOG）抓耗时代价。最后梳理生产环境真正该盯的指标。

本节目标

• 读懂 INFO 的主要分段（内存、客户端、持久化、统计、复制、键空间）及关键字段。
• 用 redis-benchmark 做基准压测并解读吞吐结果。
• 用 SLOWLOG 捕获并排查执行过慢的命令。
• 建立一套核心监控指标清单（内存、命中率、连接、延迟）。
• 避免监控中的常见误判。

---

一、INFO：实例的体检报告

INFO 返回当前实例的运行时信息，按分段组织。不带参数返回全部，也可指定分段，例如 INFO memory、INFO stats、INFO persistence。

127.0.0.1:6379> INFO memory
# Memory
used_memory:1048576
used_memory_human:1.00M
used_memory_rss:5242880
used_memory_peak:2097152
used_memory_peak_human:2.00M
mem_fragmentation_ratio:5.00
maxmemory:0
maxmemory_policy:noeviction

几个必须认识的内存字段：

• used_memory：Redis 分配器实际使用的内存字节数（数据集口径）。
• used_memory_rss：操作系统视角 Redis 占用的物理内存（含碎片）。
• mem_fragmentation_ratio：used_memory_rss / used_memory，比值远大于 1 表示内存碎片较多；接近 1 健康；小于 1 说明部分数据被换到交换区（危险）。
• maxmemory / maxmemory_policy：内存上限与淘汰策略（见第 17 章）。

再看客户端与统计分段：

127.0.0.1:6379> INFO clients
# Clients
connected_clients:12
blocked_clients:0
maxclients:10000

127.0.0.1:6379> INFO stats
# Stats
total_connections_received:1423
total_commands_processed:98765
instantaneous_ops_per_sec:1234
expired_keys:321
evicted_keys:0
keyspace_hits:80123
keyspace_misses:5021

instantaneous_ops_per_sec 是实时 QPS；keyspace_hits 与 keyspace_misses 之比可得缓存命中率，是判断缓存是否有效的最直接指标。

持久化与复制分段（INFO persistence、INFO replication）则分别反映 RDB/AOF 状态与主从同步进度，排障时必看。

二、redis-benchmark：测出极限吞吐

redis-benchmark 是 Redis 自带的压测工具，在操作系统 shell 中执行（不是 redis-cli 内部命令）。最基本用法：

redis-benchmark -n 10000 -q

-n 指定总请求数，-q 只输出每秒请求数。典型输出（数值随机器而异）：

PING_INLINE: 141043.72 requests per second
PING_BULK: 142857.14 requests per second
SET: 141442.72 requests per second
GET: 145348.83 requests per second
INCR: 137362.64 requests per second
LPUSH: 145348.83 requests per second
LPOP: 146198.83 requests per second
SADD: 146198.83 requests per second
LRANGE_100 (first 100 elements): 58411.21 requests per second
MSET (10 keys): 93283.58 requests per second

可以看到简单命令（GET/SET）轻松达到十万级 QPS，而 LRANGE 取的元素越多吞吐越低——这正是「避免大范围查询」的量化依据。

常用参数：

选项	含义	默认值
-h	服务器主机名	127.0.0.1
-p	服务器端口	6379
-c	并发连接数	50
-n	总请求数	10000
-d	SET/GET 值的数据大小（字节）	2
-r	随机键（避免单一热键）	—
-P	管道并行请求数	1
-t	仅运行指定命令列表，如 set,lpush	—
-q	静默，仅显示 QPS	—
-l	循环永久测试	—

针对特定命令做压测：

redis-benchmark -h 127.0.0.1 -p 6379 -t set,lpush -n 100000 -q

两个进阶参数值得注意：-P 16 开启管道并行，把多条命令打包在一次往返里，吞吐往往翻倍（前提是客户端也能这样用）；-r 100000 使用随机键，避免所有请求打在同一个热键上、更接近真实分布。解读原则：压测要在贴近生产的条件下进行（并发数、值大小、数据结构、是否跨网络）。单机和集群、本地回环与真实网络的差距巨大，别把回环压测数字直接当 production SLA。

三、SLOWLOG：抓住慢命令

再快的 Redis，遇到 KEYS *、超大的 LRANGE、复杂 Lua 也会卡住单线程。SLOWLOG 记录执行时间超过阈值的命令，是定位性能抖动的关键。

阈值由 slowlog-log-slower-than 控制（单位微秒，默认 10000 即 10 毫秒），日志条数由 slowlog-max-len 控制（默认 128，来自 redis.conf）：

127.0.0.1:6379> CONFIG SET slowlog-log-slower-than 10000
OK
127.0.0.1:6379> CONFIG SET slowlog-max-len 128
OK

查看最近 5 条慢日志：

127.0.0.1:6379> SLOWLOG GET 5
1) 1) (integer) 14
   2) (integer) 1764567890
   3) (integer) 12000
   4) 1) "LRANGE"
      2) "mylist"
      3) "0"
      4) "-1"

每条日志含：唯一 id、时间戳、耗时（微秒）、命令及参数。看到 KEYS、全量 LRANGE、FLUSHALL 之类出现在慢日志，就是优化信号——改用 SCAN、LRANGE 分页或加索引结构。

127.0.0.1:6379> SLOWLOG LEN
(integer) 3
127.0.0.1:6379> SLOWLOG RESET
OK

SLOWLOG LEN 看数量，SLOWLOG RESET 清空日志（排查完一轮后清理，便于下一轮观察）。

四、键空间与延迟：从 INFO 到 LATENCY

4-1 键空间分段

INFO keyspace 反映每个数据库的键数量与带过期键的数量，是判断「缓存是否在工作」的快捷入口：

127.0.0.1:6379> INFO keyspace
# Keyspace
db0:keys=12345,expires=9800,avg_ttl=3600000

keys 是总键数，expires 是其中设了过期的数量，avg_ttl 是平均剩余寿命（毫秒）。如果 expires 长期为 0，说明你可能忘了给缓存设过期，最终会撑爆内存。

4-2 延迟监控 LATENCY

除了命令本身的慢，端到端延迟还受网络、磁盘、fork 子进程等影响。Redis 提供 LATENCY 子命令做内置延迟诊断。先在 redis.conf 打开监控阈值（latency-monitor-threshold，默认 0 表示关闭）：

127.0.0.1:6379> CONFIG SET latency-monitor-threshold 100
OK

随后查看最近一次超过阈值的事件类型与耗时：

127.0.0.1:6379> LATENCY LATEST
1) 1) "fork"
   2) (integer) 1764567890
   3) (integer) 1500
   4) (integer) 1200

这里 fork 事件（RDB/AOF 重写时复制内存）耗时 1.5 毫秒，是常见延迟来源。另一个常用手段是 redis-cli --latency 在客户端侧持续测量往返延迟：

redis-cli --latency -h 127.0.0.1 -p 6379
min: 0, max: 2, avg: 0.12 (1024 samples)

平均 0.12 毫秒属于健康；若经常跳到几十毫秒，要检查网络、持久化阻塞或实例是否超配。

五、生产应关注的核心指标

把上面串起来，生产监控建议盯住这几条：

1. 内存：used_memory 接近 maxmemory 时触发淘汰；碎片率异常要警惕。
2. 命中率：keyspace_hits / (hits + misses)，低于 80%~90% 通常说明缓存设计有问题。
3. 连接数：connected_clients 持续攀升可能意味着连接泄漏；对照 maxclients。
4. 延迟：用 redis-cli --latency 或 LATENCY 相关命令测端到端延迟；latency-monitor-threshold（默认 0 关闭）可开启内置延迟监控。
5. 慢日志频率：频繁出现慢命令是容量或代码问题的前兆。
6. 复制与持久化：从节点延迟、最近 RDB/AOF 状态，关系到容灾可用性。

六、常见误区

• 误区一：「压测十万 QPS，生产也能扛。」回环压测不含网络、不含真实数据结构，结论会严重偏高。
• 误区二：「命中率低就加大内存。」先查是不是 key 设计混乱、过期太短或热点集中，盲目加内存治标不治本。
• 误区三：「慢日志为空就是健康。」阈值设太高（如 100ms）会漏掉很多「亚健康」命令，建议按业务敏感度调到 1~10ms 量级观察。
• 误区四：「只看 used_memory 不看 rss。」碎片率飙高时 rss 远大于 used_memory，物理内存可能被吃满而数据集并不大。

---