perf 定位进程内热点
确认 CPU 确实花在 Redis 进程内之后，perf 能把开销落到具体函数：perf top 实时显示符号级热点，perf record 采样后配合 report 查看调用栈。它是排障链条的最后一层——先用慢查询日志与延迟监控把范围缩小，再用采样确认具体代码路径，而不是一上来就抓全局。
基本信息
| 实时观察 | perf top -p <pid> |
|---|---|
| 采样分析 | perf record -p <pid> -g -- sleep 30，再用 perf report |
| 输出 | 函数级符号与占比 |
| 前提 | 二进制带调试符号，且有足够的采样权限 |
| 开销 | 采样本身有成本，必须控制时长 |
| 配套工具 | SLOWLOG、latency-monitor-threshold 与 LATENCY 系列命令 |
典型使用场景
- 复杂命令定位：命令 CPU 高但看不出原因时，看热点落在哪段代码
- 优化效果验证：改完数据结构后重新采样，确认热点消失
- 判断瓶颈层次：热点集中在系统调用说明瓶颈在 IO 或网络
- 与慢日志配合：慢日志给出哪些命令慢，采样解释它为什么慢
- 重构决策：采样结果高度集中在一个函数时，说明该路径值得重构
最小示例
最小示例
redis-cli SLOWLOG GET 10 # 先确认哪些命令慢
redis-cli CONFIG GET latency-monitor-threshold # 延迟监控阈值设置
redis-cli LATENCY DOCTOR # Redis 给出的延迟成因提示
sudo perf top -p <redis_pid> # 实时函数级热点
sudo perf record -p <redis_pid> -g -- sleep 30 # 采样 30 秒
sudo perf report # 查看采样报告观察重点
| 观察 | 含义 | 优化方向 |
|---|---|---|
| 热点集中在结构遍历 | 命令复杂度是主因 | 换复杂度更低的命令或拆分结构 |
| 热点集中在内存拷贝 | 单次命令数据量过大 | 分批处理，控制单次返回体量 |
| 热点集中在系统调用 | IO 或网络成为瓶颈 | 检查持久化策略、网卡与连接数 |
| 符号显示为地址 | 二进制缺少符号信息 | 安装调试符号包或重新编译后再采样 |
先用慢日志与延迟监控缩小范围，再用 perf 落点：直接全局采样得到的多是噪声，定位效率反而更低。
容器与较新内核上默认权限可能不足，需要调整采样相关的内核参数或给容器相应能力，动手前确认合规要求。