Производительность кластера Redis — высокая частота тайм-аутов при низкой нагрузке

Посмотрите на странное поведение кластера Redis, который отлично работает при большой нагрузке и начинает работать с тайм-аутом 50% и нестабильным временем отклика при низкой нагрузке.

У нас такая же скороговорка каждый день в периоды низкой нагрузки.

Любые идеи, что могло вызвать такой странный образец? Может быть, некоторые работы по техническому обслуживанию, которые этот RedisCluster начинает выполнять при низком времени загрузки? Например, ребалансировка слотов. Пожалуйста, порекомендуйте какие-либо настройки или аспекты для проверки.

Версии: Redis 2.0.7, Джедис 2.8.1

Конфигурация: 3 физических узла с 9 ведущими процессами и 18 подчиненными.

Время ожидания JedisCluster = 5 мс.

Загрузка 100% пишет сетексом.

Время отклика JedisCluster Частота времени ожидания JedisCluster

Эти графики относятся к времени отклика JedisCluster, а не к фактическому времени RedisCluster. Строка «Наборы» здесь — это фактически успешные наборы, а не общее количество.


performance redis redis-cluster jedis
person Dmitry Spikhalskiy    schedule 12.04.2016    source источник
comment
у вас есть поиск DNS при подключении к RedisCluster?   -  person Slach    schedule 18.04.2016
comment
@Slach нет, мы подключаемся по IP и используем пул соединений через Jedis, поэтому переподключение происходит редко.   -  person Dmitry Spikhalskiy    schedule 19.04.2016

Ответы (1)


arrow_upward
6
arrow_downward

Наконец я обнаружил, что это похоже на проблему с сетью.

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

Глядя на «if_octets» collectd, мы наблюдаем огромную сетевую активность на сетевых интерфейсах в это время низкой активности записи. Ночная нагрузка примерно в 10 раз больше, чем дневная.

И это вызвано узлами redis, которые начинают активно обмениваться информацией в этот период низкой нагрузки. Вывод основных подключений Iptraf: Вывод Iptraf, большая часть пакетов и трафика проходит между узлами/процессами redis В то время как в дневное время в этом отчете iptraf полностью принадлежит реальным клиентам Redis с хорошей нагрузкой на запись.

Наконец обнаружил, что у нас проблемы с репликацией. Иногда буфера не хватало и слейвы начинали полную ресинхронизацию. Похоже на эту ночную нагрузку - полные попытки повторной синхронизации + низкое значение времени ожидания репликации - в результате бесконечные попытки репликации. Почему эта репликация так сильно влияет на низкую ночную нагрузку и не влияет на дневное время — я не знаю, не вижу опций, заставляющих редис чаще делать попытки по ночам или что-то в этом роде. Если интересно, мы исправили бесконечную репликацию, увеличив очевидные настройки:

repl-backlog-size
repl-timeout
person Dmitry Spikhalskiy    schedule 19.04.2016