9

看到 redis 集群的奇怪行为，它在大负载下运行良好，并以 50% 的超时率和低负载下不稳定的响应时间开始运行。

在低负载期间，我们每天都有相同的模式。

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

版本：Redis 2.0.7、Jedis 2.8.1

配置：3 个物理节点，9 个主进程和 18 个从属。

JedisCluster 超时 = 5 毫秒。

负载是 100% 使用 setex 写入。

JedisCluster 响应时间 JedisCluster 超时率

此图适用于 JedisCluster 响应时间，而不是实际 RedisCluster 时间。这里的“Sets”行实际上是成功的集合，而不是总数。

4

1 回答 1

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

看看 collectd 的“if_octets”，在这个低写入活动的时候，我们在网络接口上有大量的网络活动。夜间负载是白天负载的 10 倍。

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

最后发现我们有复制问题。有时缓冲区不够，从站开始完全重新同步。看起来像这个夜间负载 - 完全重新同步尝试 + 低 repl-timeout 值 - 结果是无休止的复制尝试。为什么这种复制会如此显着地影响夜间低负载并且不会影响白天 - 我不知道，没有看到任何选项可以让 redis 更频繁地在夜间或类似的事情上进行尝试。如果有趣的话，我们通过增加明显的设置来修复无休止的复制：

repl-backlog-size
repl-timeout
于 2016-04-19T12:39:23.123 回答