latency doctor能诊断redis内部延迟事件（如事件循环中断、命令执行超时、aof写入阻塞、fork耗时等），不能诊断内核态问题（如/proc/pid/smaps页表锁争用、thp启用、swap缺页、cpu调度延迟）。
LATENCY DOCTOR 能诊断什么，不能诊断什么
LATENCY DOCTOR 是 Redis 内置的延迟根因分析器，它只观测 Redis 进程内部可感知的延迟事件：比如 eventloop 中断、command 执行超时、aof_fsync 阻塞、eviction 压力、fork 系统调用耗时等。它不采集内核态行为，对以下情况完全无感：
-
/proc/pid/smaps读取引发的页表锁争用（如atop -R或cadvisor） - 透明大页（THP）启用导致的
mm/mmap.c级别卡顿 - swap in/out 引起的缺页中断等待
- CPU 抢占、调度延迟、NUMA 远端内存访问
换句话说：如果 LATENCY DOCTOR 说“没发现明显问题”，不代表系统没问题——只是 Redis 自己没“感觉到”被拖慢。
执行 LATENCY DOCTOR 的正确姿势
直接在 redis-cli 中运行即可，但要注意上下文和解读方式：
- 必须在毛刺发生后 **1 分钟内** 执行，它只分析最近 60 秒的延迟事件
- 输出中优先看
maxmemory-policy is noeviction这类提示：它说明写入被拒，不是延迟问题 - 若提示
bgrewriteaof or bgsave is running，要立刻检查save配置或auto-aof-rewrite-percentage是否过高 - 搭配
LATENCY LATEST查看最近一次毛刺的精确时间戳，再用journalctl --since "2026-09-06 02:45:00"对齐系统日志
为什么 LATENCY DOCTOR 有时“查不出东西”却仍有毛刺
常见真实场景下，Redis 主线程在用户态空转，但实际被内核卡住，典型表现是：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
redis-cli --intrinsic-latency 100测出延迟正常（GET 命令 P99 > 10ms -
LATENCY HISTORY显示平滑，LATENCY DOCTOR返回No problem detected - 同时
ps aux | grep atop发现后台正跑着atop -R，或cadvisor未关闭 memory metrics
这时应立刻验证内核锁争用：perf record -e 'syscalls:sys_enter_read' -p $(pgrep redis-server) -g -- sleep 10，然后 perf report 看是否大量 read 调用堆在 mm/mmap.c 路径上。
真正该查的三个系统级信号
遇到毛刺，别只翻 redis.log，先确认这三个外部事实：
- 运行
cat /sys/kernel/mm/transparent_hugepage/enabled：输出是[always]就是高频根因，需立即设为never - 执行
ps aux | grep -E "(atop|cadvisor)"：特别注意带-R的 atop 和未加--disable_metrics=memory的 cadvisor - 检查 swap 活动：
grep -i "swapped" /proc/vmstat或vmstat 1 5看si/so列是否非零
这些信号比 LATENCY DOCTOR 的输出更早暴露问题——因为它们发生在 Redis 看不见的地方。
