CPU 高要去哪里看
Redis 是单线程处理命令的，CPU 飙高基本可以归到四类来源：命令本身的复杂度（大 key、全量遍历、热键集中）、过期与淘汰集中触发、后台任务（快照 fork 与 AOF 重写）、以及网络与加密带来的开销。排查的诀窍是先用 INFO 分段把方向缩小，再决定是改命令、改数据设计还是改部署方式，不要一上来就加机器。
基本信息
| 适用平台 | Redis 全版本；字段名随版本略有差异 |
|---|---|
| 主要入口 | INFO cpu、INFO commandstats、INFO stats、INFO persistence |
| 辅助命令 | SLOWLOG、redis-cli --hotkeys（需 LFU）、--bigkeys |
| 重置统计 | CONFIG RESETSTAT 可清零累计计数 |
| 观察窗口 | 至少覆盖一个完整业务周期 |
典型使用场景
- 实例 CPU 长期高于 60%，但慢查询不多
- 业务高峰期出现响应毛刺，需要区分是命令开销还是后台任务
- 排查大 key：单个命令扫描数十万成员
- 过期键集中在同一时刻触发导致的周期性 CPU 峰值
- 评估加密传输或复制流量带来的额外开销
定位命令
定位命令
INFO cpu # 查看 user/sys 时间占比
INFO commandstats | head -20 # 各命令族的调用次数与耗时
SLOWLOG GET 20 # 最近的慢命令
INFO stats | grep -E 'expired_keys|evicted_keys|instantaneous_ops_per_sec'
INFO persistence | grep -E 'rdb_bgsave_in_progress|aof_rewrite_in_progress|latest_fork_usec'
redis-cli --bigkeys # 查找大 key（低峰执行）
CONFIG RESETSTAT # 采样前清零，便于观察增量四类来源与处置
| 来源 | 判断依据 | 处置方向 |
|---|---|---|
| 命令复杂度 | commandstats 中某命令族耗时占比高 | 改数据结构、拆分大 key、避免全量遍历 |
| 热键集中 | 单键 QPS 占比过高 | 本地缓存、多副本分摊、写合并 |
| 过期与淘汰集中 | expired_keys 与 evicted_keys 出现尖峰 | 打散 TTL、避免同一时刻集体过期 |
| 后台任务 | fork 耗时高或重写进行中 | 关闭 THP、错峰执行、评估内存规模 |
| 网络与加密 | sys 时间占比偏高、TLS 流量大 | 评估启用加密的必要性，减少大响应 |
commandstats 是累计值：采样前先 CONFIG RESETSTAT，间隔一段时间后再读，才能反映当前窗口的真实分布，否则历史峰值会一直压在榜首。
不要在高峰期执行 --hotkeys 与 --bigkeys：这类命令需要扫描全键空间，本身就是一次可观的 CPU 开销，会把已经偏高的负载再推高一层。