Redis群集性能 - 低负载时的高超时率

Dmi*_*kiy 9 performance redis jedis redis-cluster

查看redis集群的奇怪行为,它在大负载下运行完全正常,并且在低负载下以50%的超时速率和不稳定的响应时间开始运行.

我们在低负荷期间每天​​都有相同的模式.

什么想法会导致这种奇怪的模式?也许这个RedisCluster在低负载时间开始做一些维护工作?像插槽重新平衡.请推荐任何设置或方面进行检查.

版本:Redis 2.0.7,Jedis 2.8.1

配置:3个物理节点,9个主进程和18个从属.

JedisCluster Timeout = 5ms.

使用setex加载是100%写入.

JedisCluster响应时间 JedisCluster超时率

此图表适用于JedisCluster响应时间,而不是实际的RedisCluster时间.这里的"设置"行实际上是成功设置,而不是总计数.

Dmi*_*kiy 6

最后我发现它看起来像网络问题.

redis08(10.201.12.214) ~ $ redis-benchmark -h 10.201.12.215 -p 9006
====== PING_INLINE ======
  100000 requests completed in 91.42 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 11 milliseconds

redis09(10.201.12.215) ~ $ redis-benchmark -h 10.201.12.215 -p 9006
====== PING_INLINE ======
  100000 requests completed in 1.41 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.46% <= 1 milliseconds

redis08 ~ $ ping lga-redis09
PING redis09 (10.201.12.215) 56(84) bytes of data.
64 bytes from redis09 (10.201.12.215): icmp_seq=1 ttl=64 time=10.7 ms
Run Code Online (Sandbox Code Playgroud)

看看collectd的"if_octets",在这个低写入活动时,我们在网络接口上有巨大的网络活动.与白天负荷相比,夜间负荷为10倍.

它是由redis节点引起的,它们开始在这个低负载期间主动交换信息.Iptraf顶部连接输出: Iptraf输出,大多数数据包和流量都在redis节点/进程本身之间 虽然在这个iptraf报告的日间顶部完全属于具有良好写入负载的实际redis客户端.

终于发现我们有复制问题.有时缓冲区不够,奴隶开始完全重新同步.看起来像这个夜晚加载 - 完全重新同步尝试+低重复超时值 - 结果是无休止的复制尝试.为什么这种复制对夜间负荷影响如此显着而且不影响白天时间 - 我不知道,看不到任何选项让redis更经常地尝试夜晚或类似的事情.如果它很有趣,我们通过增加明显的设置来修复无休止的复制:

repl-backlog-size
repl-timeout
Run Code Online (Sandbox Code Playgroud)