Redis hz 与 dynamic-hz

默认值

> CONFIG GET hz
1) "hz"
2) "10"
> CONFIG GET dynamic-hz
1) "dynamic-hz"
2) "yes"
  INFO server: hz = 10  configured_hz = 10

hz 默认 10,dynamic-hz 默认 yes。INFO server 里的 hz 是当前实际值,configured_hz 是配置值。

hz 与过期事件的及时性

   hz       事件延迟 中位 ms     最大 ms
    1            702.1    1704.2
   10              6.0       6.5
  100              7.5      21.1

hz 1 时后台扫描每秒一次,expired 事件比 TTL 晚的中位数 702 ms、最大 1704 ms(约一个扫描周期);hz 10 时中位数 6.0 ms;hz 100 时 7.5 ms,没有比 hz 10 更好。注意:这是空闲实例、少量 key 的情形;第 51 篇里量到,当库里有大量长 TTL 的 key 时,过期回收的及时性主要取决于抽样,而不是 hz 本身(那时没有测 hz 调大是否有帮助)。

hz 的代价

   hz    10 秒内 CPU 秒      折合每秒 ms
   10          0.013         1.27
  100          0.032         3.15
  500          0.071         7.07

空闲实例 10 秒消耗的 CPU:hz 10 是 0.013 s,hz 100 是 0.032 s,hz 500 是 0.071 s,大致随 hz 线性增长。绝对值很小(hz 500 也只是每秒约 7 ms),这是空闲实例、本机的数字;数据量大时每次 cron 的工作量也会变。

dynamic-hz

    已连接客户端    hz  configured_hz
         1    10             10
       100    10             10
       500    10             10
      2000    10             10
      4000    20             10

开着 dynamic-hz 时,连接数很多会自动提高实际 hz(configured_hz 不变)。本次测量里 500、2000 个连接时实际 hz 都还是 10,4000 个连接时才变成 20。触发的具体规则我没有去查源码,只记录了这几个点,中间没有二分。

分步演示:hz 的两面