Redis Lua脚本执行过程中如何监测CPU占用情况？

Redis不提供实时Lua脚本级CPU统计，需结合INFO cpu差值、SLOWLOG（调低slowlog-log-slower-than）、perf（用--call-graph dwarf而非-g）及monitor交叉验证，定位evalGenericCommand或luaV_execute等热点函数及对应EVAL命令。

Redis 本身不提供实时 Lua 脚本级 CPU 占用统计，EVAL 或 EVALSHA 执行时的 CPU 消耗完全计入 Redis 主进程的 used_cpu_user 累计值，无法按脚本拆分。想定位“哪个 Lua 脚本吃 CPU”，必须结合外部观测 + 内部命令交叉验证。

用 INFO cpu 看累计消耗趋势，不是实时占用率

INFO cpu 返回的是自进程启动以来的累计 CPU 秒数（used_cpu_user 和 used_cpu_sys），不是百分比或瞬时值。它只适合做差值计算——比如每 5 秒采一次，算出 Δused_cpu_user / 5，再对比其他时段是否突增。

1. 直接看单次 INFO cpu 输出毫无意义：数值大只说明实例运行久，不等于当前忙
2. 若发现 Δused_cpu_user 在某段时间内明显高于 Δused_cpu_sys，大概率是 Lua 脚本或客户端命令解析在用户态耗时多
3. 注意：used_cpu_user_children 始终为 0（Redis 无子进程执行 Lua），别被字段名误导

用 SLOWLOG 捕获长耗时 Lua 调用，但需提前配置

SLOWLOG 是唯一能关联到具体 EVAL 命令的内置机制，但它默认不记录 Lua 执行时间——除非你手动调大阈值。

1. 执行 CONFIG SET slowlog-log-slower-than 1000（单位微秒），否则默认 10000 微秒（10ms）只捕获极慢脚本，漏掉多数问题
2. SLOWLOG GET 10 返回结果中，第三字段是执行耗时（微秒），第二字段是命令完整内容，能看到 EVAL "return redis.call..." 这类原始脚本片段
3. 风险点：设太低（如 100）会导致日志爆炸；设太高（如 50000）可能错过真实问题脚本
4. 注意：SLOWLOG 不记录 EVALSHA 的原始脚本内容，只显示哈希值，需配合 SCRIPT DEBUG YES + 日志回溯

用 perf 定位热点函数，但别用 -g

当 top 显示 redis-server CPU 100% 且 SLOWLOG 无异常时，说明问题在底层执行路径，要用 perf 看真实热点。

1. 错误做法：perf record -p $(pgrep redis-server) -g -- sleep 30 —— -g 会强制栈展开，在高吞吐下反而把 Redis 拖更慢
2. 正确命令：perf record -p $(pgrep redis-server) --call-graph dwarf -F 99 -- sleep 30，其中 --call-graph dwarf 避免因编译选项缺失导致符号丢失
3. 关键观察点：perf report 中若 evalGenericCommand、lua_pcall、luaV_execute 占比高，基本锁定是 Lua 解释器开销；若大量 sdsnewlen 或 ziplistPush，说明脚本在构造大量字符串或遍历 ziplist 编码结构体
4. 别被 epoll_wait 占比高迷惑——那是正常阻塞等待，真正问题一定出现在用户态函数里

用 redis-cli monitor 辅助判断，但别信它的实时性

redis-cli monitor 在 CPU 已 100% 时会严重滞后，但它仍可帮你确认是否有高频 EVAL 流量涌入。

1. 如果 monitor 输出里连续出现相同 EVALSHA 哈希，且间隔稳定（如每 200ms 一次），基本就是定时任务或客户端轮询触发的脚本风暴
2. 若输出卡住几秒才刷出一批命令，说明主线程已调度不过来，此时 SCRIPT KILL 可能无效，得先看 INFO replication 是否从库同步积压拖累主库
3. 注意：monitor 自身也走事件循环，CPU 100% 时它和客户端请求一样排队，看到的不是“正在发生”，而是“刚挤进来”的残影

真正难的不是采集数据，而是把 perf 里的 luaV_execute 热点、SLOWLOG 里的哈希值、业务侧的定时任务逻辑三者对上——中间缺一环，就只能靠猜。Lua 脚本一旦上线，它的 CPU 开销就彻底融入 Redis 主线程，没有独立监控维度，所有分析都得靠间接证据拼图。