--intrinsic-latency 是什么
redis-cli --intrinsic-latency 秒数 测量的是机器本身的固有延迟：它在紧密循环里反复读时钟，统计两次读取之间最长被中断了多久，全程不连 Redis、不涉及网络。它回答的是「这台机器最好能做到多稳」，是延迟排查的第一块基线——基线差，后面无论怎么优化命令都事倍功半。
基本信息
| 命令 | redis-cli --intrinsic-latency <秒数> |
|---|---|
| 测量对象 | 本机调度与内核固有延迟，不含网络与 Redis |
| 前提 | 机器应处于空闲状态 |
| 输出 | 累计次数、平均每次循环耗时与最大延迟 |
| 时长建议 | 跑得越久越容易抓到尖峰，生产基线常用 100 秒左右 |
| 配套命令 | redis-cli --latency、--latency-history |
典型使用场景
- 新机器验收：确认交付的宿主本身能撑住低延迟服务
- 排查「Redis 变慢」：先测基线，把机器与虚拟化问题排除掉
- 选型对比：同一规格在不同宿主上跑一遍，择优部署
- 内核调优验证：关闭节能降频、调整调度策略后复测
- 与端到端延迟对照：区分是机器慢、网络慢还是命令慢
最小示例
最小示例
uptime # 先确认机器确实空闲
redis-cli --intrinsic-latency 10 # 快速估一遍
taskset -c 2 redis-cli --intrinsic-latency 60 # 绑定到指定核，减少跨核抖动
redis-cli --latency-history -i 5 # 与端到端延迟对照
redis-cli --latency -h 目标主机 # 从客户端侧测网络往返结果怎么读
| 观察 | 含义 | 下一步 |
|---|---|---|
| 最大延迟几十微秒级 | 空闲物理机的常见水平 | 机器侧没问题，转向网络与命令层 |
| 出现毫秒级尖峰 | 调度或虚拟化层面有抖动 | 查超卖、节能降频、swap、同宿主邻居 |
| 平均稳定但偶发高峰 | 存在间歇性抢占 | 结合时间点找干扰源，必要时隔离 CPU |
| 去掉其他负载后仍很差 | 宿主规格或虚拟化本身不适合 | 换实例规格或类型再验 |
它不连接 Redis，所以结论只关于机器。要和 --latency / --latency-history 的端到端结果对照，才能判断瓶颈在机器、网络还是命令执行。
单个进程只压一个核，多核机器上要评估整机应并行跑多份并分散到不同核，取各核中最差的结果作为基线。
机器上有业务负载时测出的结果混入了别人的开销，不能当基线；同样也不要据此直接下结论说 Redis 慢。