Redis 延迟监控

在 Redis 中发现慢速服务器事件

Redis 通常用于要求苛刻的使用案例，其中 每个实例每秒提供大量查询，但对平均响应也有严格的延迟要求 time 和最坏情况下的延迟。

虽然 Redis 是一个内存系统，但它处理 不同的方式，例如，在 persisting to disk 的上下文中。 此外，Redis 实现了一组丰富的命令。某些命令 速度快，并以恒定或对数时间运行。其他命令速度较慢 O（N） 命令，这可能会导致延迟峰值。

最后，Redis 是单线程的。这通常是一个优势 从每个内核可以执行的工作量的角度来看，在 它能够提供的延迟数字。然而，它摆出 这是一个延迟的挑战，因为单个 thread 必须能够增量执行某些任务，因为 密钥过期示例，以不影响其他客户端的方式 被服务。

由于所有这些原因，Redis 2.8.13 引入了一项称为延迟监控的新功能，可帮助用户检查和排除可能的故障 延迟问题。延迟监控由以下概念组成 部件：

• 对不同的延迟敏感型代码路径进行采样的延迟挂钩。
• 延迟峰值的时间序列记录，按不同事件划分。
• Reporting engine 从时间序列中获取原始数据。
• 分析引擎，根据测量值提供人类可读的报告和提示。

本文档的其余部分介绍了延迟监控子系统 详。有关 Redis 的一般主题的更多信息 和延迟，请参阅 Redis 延迟问题故障排除。

事件和时间序列

不同的受监控代码路径具有不同的名称，称为事件。 例如command是一个事件，用于测量可能较慢的延迟峰值 命令执行，而fast-command是监控的事件名称 O（1） 和 O（log N） 命令。其他事件不太通用，并且具有监视性 Redis 执行的具体作。例如，fork事件 仅监控 Redis 执行fork(2)system 调用。

延迟峰值是指运行时间超过配置的延迟的事件 门槛。有一个单独的时间序列与每个监控 事件。时间序列的工作原理如下：

• 每次发生延迟峰值时，都会将其记录在适当的时间序列中。
• 每个时间序列由 160 个元素组成。
• 每个元素都是一对，由测量延迟峰值的时间的 Unix 时间戳和执行事件所花费的毫秒数组成。
• 同一秒内发生的同一事件的延迟峰值通过采用最大延迟来合并。即使为给定事件测量了连续延迟峰值（在低阈值下可能会发生），也至少有 160 秒的历史记录可用。
• 记录每个元素的历史最大延迟。

框架会监控并记录这些事件执行时间中的延迟峰值：

• command：常规命令。
• fast-command： O（1） 和 O（log N） 命令。
• fork：这fork(2)system 调用。
• rdb-unlink-temp-file：这unlink(2)system 调用。
• aof-fsync-always：这fsync(2)system 调用时由appendfsync allways政策。
• aof-write：写入 AOF - 的 catchall 事件write(2)system 调用。
• aof-write-pending-fsync：这write(2)system 调用。
• aof-write-active-child：这write(2)system 调用。
• aof-write-alone：这write(2)system 调用（当没有待处理的 fsync 且没有活动的子进程时）。
• aof-fstat：这fstat(2)system 调用。
• aof-rename：这rename(2)完成后重命名临时文件的 system 调用BGREWRITEAOF.
• aof-rewrite-diff-write：写入执行时累积的差异BGREWRITEAOF.
• active-defrag-cycle：主动碎片整理周期。
• expire-cycle：过期周期。
• eviction-cycle：驱逐周期。
• eviction-del：在逐出周期内删除。

如何启用延迟监控

对于一个使用案例来说，什么是高延迟对于另一个使用案例来说可能不被视为高延迟。某些应用程序可能要求在 1 毫秒内提供所有查询。对于其他应用程序，少数客户端偶尔遇到 2 秒的延迟可能是可以接受的。

启用延迟监控器的第一步是设置延迟阈值（以毫秒为单位）。只有时间超过指定阈值的事件才会被记录为延迟峰值。用户应根据自己的需要设置阈值。例如，如果应用程序需要最大可接受的延迟为 100 毫秒，则应将阈值设置为记录阻止服务器的所有事件，时间等于或大于 100 毫秒。

在生产服务器中的运行时启用延迟监视器 使用以下命令：

CONFIG SET latency-monitor-threshold 100

默认情况下，监控处于关闭状态（阈值设置为 0），即使延迟监控的实际成本接近于零。虽然延迟监控的内存要求非常小，但没有充分的理由提高运行良好的 Redis 实例的基准内存使用量。

使用 LATENCY 命令报告信息

延迟监控子系统的用户界面是LATENCY命令。 与许多其他 Redis 命令一样，LATENCY接受修改其行为的子命令。这些子命令是：

• LATENCY LATEST- 返回所有事件的最新延迟样本。
• LATENCY HISTORY- 返回给定事件的延迟时间序列。
• LATENCY RESET- 重置一个或多个事件的延迟时间序列数据。
• LATENCY GRAPH- 呈现事件延迟样本的 ASCII 艺术图。
• LATENCY DOCTOR- 回复人类可读的延迟分析报告。

有关更多信息，请参阅每个子命令的文档页面。