Redis单线程下BITFIELD GET慢查询（1500-2000μs）排查咨询

针对你遇到的问题——Lua脚本中的简单BITFIELD GET操作耗时1500-2000微秒，而主机CPU处于正常水平，这里提供几个具体的排查方向：

• 确认慢日志的统计对象：Redis默认慢日志记录的是整个Lua脚本的执行时间，而非脚本内的单个命令。先通过SLOWLOG GET查看慢日志条目的详细信息，确认是否是脚本整体的执行耗时被标记为慢查询，而非单独的BITFIELD操作。如果是脚本整体耗时，需要重点分析脚本中其他步骤的开销。

• 检查目标键的特性与状态：

  • 查看键对应字符串值的大小：如果值非常大（比如超过1MB），即使是GET前32位，Redis在处理时可能涉及额外的内存寻址或编码转换开销；可以用STRLEN命令快速查看键的长度。
  • 确认键是否存在过期或惰性删除逻辑：如果键即将过期，或者正在被惰性删除流程处理，可能会额外增加操作的延迟。
  • 检查键的访问冲突：如果该键被其他客户端频繁修改（比如SET、BITFIELD SET等操作），可能会导致Redis内部的锁竞争，间接影响读取性能。

• 排查Redis后台活动的影响：

  • 查看持久化状态：通过INFO persistence检查RDB快照或AOF重写是否在进行，即使CPU正常，磁盘IO阻塞也可能导致主线程出现短暂延迟；重点关注rdb_last_bgsave_time_sec、aof_last_fsync_time_sec等指标。
  • 检查内存回收活动：如果Redis内存接近阈值，后台自动内存回收（比如主动淘汰过期键）可能会占用主线程时间，影响命令执行速度；可以用INFO memory查看used_memory与maxmemory的比例，以及evicted_keys指标。

• 分析Lua脚本的完整逻辑：

  • 即使单个BITFIELD GET操作简单，脚本中可能存在其他隐藏的耗时操作，比如循环遍历键列表、复杂的条件判断、多次Redis命令调用等。完整审查脚本代码，确认是否有其他步骤累积了执行时间。
  • 注意Lua脚本的原子性：脚本执行期间会阻塞其他所有请求，如果脚本执行时间长，可能会让后续请求的延迟看起来更高，但核心还是要定位脚本内的具体耗时点。

• 系统层面的资源排查：

  • 检查Redis进程的CPU核心占用：Redis是单线程模型，会绑定一个CPU核心，如果该核心被其他进程（如系统服务、其他应用）占用，会导致Redis线程调度延迟。用pidstat -p <redis-pid> 1查看该进程的CPU使用率和上下文切换次数（cs列），如果上下文切换频繁，说明线程调度存在竞争。
  • 排查内存交换：如果Redis使用了swap空间（INFO memory中used_memory_rss远大于used_memory），内存访问会因为磁盘交换而变慢，导致命令耗时增加。可以通过关闭swap或调整Redis内存限制来优化。

• 验证操作的实际耗时：

  • 单独执行BITFIELD GET命令（脱离Lua脚本），用redis-cli --latency-history或redis-benchmark测试该命令的单独耗时，对比脚本内的耗时差异，判断是否是脚本上下文导致的延迟。

内容的提问来源于stack exchange，提问作者sumanth232