Redis: «psync scheduled to be closed ASAP for overcoming of output buffer limits» и client-output-buffer-limit

Имеется Redis-кластер с Sentinel, см. Redis: репликация, часть 2 — Master-Slave репликация, и Redis Sentinel, Redis: fork — Cannot allocate memory, Linux, виртуальная память и vm.overcommit_memory и Redis: основные параметры конфигурации и тюнинг производительности.

Система работала отлично долгое время, пока мы не начали использовать кеш намного более активно.

Redis info

Проверить все ключи в базах можно так:

А их размеры — с помощью bigkeys:

Полезная опция --stat:

monitor:

И slowlog:

См. также latency.

К ошибке.

Ошибка «psync scheduled to be closed ASAP for overcoming of output buffer limits»

Прекрасным вечером система мониторинга сообщила о проблемах с кластером.

В логах это выглядело так:

Из всего этого текста нам важно сообщение «psync scheduled to be closed ASAP for overcoming of output buffer limits«.

«Быстрофикс» — client-output-buffer-limit

Решение — увеличить размер client-output-buffer-limit.

В двух словах — это размер буфера, используемого master-сервисом Redis для хранения данных, которые изменились в процессе синхронизации базы данных из памяти Redis-master и одного из его слейвов.

Проверяем значение сейчас:

Формат:

client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>

Дефолтные значения:

• client-output-buffer-limit normal 0 0 0
• client-output-buffer-limit slave 256mb 64mb 60
• client-output-buffer-limit pubsub 32mb 8mb 60

С такими настройками соединение будет разорвано немедленно при достижении <hard limit> — 256 МБ, либо если <soft limit> — 64 МБ — превышен дольше лимита из <soft seconds> — 60 секунд.

Нас интересует slave 268435456 67108864 60.

На Мастере увеличиваем лимит буфера до 512 метров:

Мне пришлось увеличивать буфер с 512 мегабайт до 1 гига, потом 2, 4 ,8 — и только на 10 GB синхронизация прошла успешно, при том, что база в памяти была чуть меньше 5 гигабайт:

И в логах слейва:

А теперь, когда Production снова жив, рассмотрим внимательнее.

Что вообще происходит?

Redis master-slave — процесс синхронизации

Кратко вспомним процесс синхронизации мастер-слейв:

1. слейв при запуске или после потери коннекта обращается к мастеру с просьбой передать на слейв данные из базы мастера, что бы слейв мог начать обслуживать запросы клиентов
2. мастер в ответ на этот запрос:
   1. создаёт дочерний процесс, который дампит базу Redis из памяти на диск в файл dump.rdb (см. fork() vs fork() vs clone())
   2. в это время мастер продолжает отвечать на запросы от других клиентов
   3. и любые данные, которые изменились этими клиентами с момента начала создания дампа сохраняет в буфер репликации
3. мастер сообщает слейву, что дамп готов, и слейв начинает загружать его по сети к себе, сохраняя на диск
4. слейв завершает передачу дампа к себе, загружает в память своего процесса Redis, и сообщает мастеру, что слейв готов к работе
5. мастер проверят свой буфер, и если в нём есть данные — он передаёт изх на слейв, что бы тот заменил данные в своей базе, созданной из дампа, последними, актуальными данными
6. слейв применяет изменения, и вступает в работу

Таким образом, синхронизация мастер-слейв включает в себя два этапа:

1. сначала содаётся полная копия данных, которая может содержать устаревшие данные
2. затем выполняется последовательный набор апдейтов из буфера, которые заканчвают приведение новой базы в состояние, аналогичное базе на мастере

Размер базы и буфера

Проблемы — при снапшоте может потребоваться памяти до х3 от размера базы, и главная сложность заключается даже не в том, что бы создать сам снапшот данных, а в том, что его надо передать на слейв, и при этом сохранить консистентность данных между мастером и слейвом, так как пока данные передаются по сети, с её задержками, пока слейв запишет её к себе на диск, пока загрузит к себе в память — на мастере данные успеют измениться.

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

В теории — размер буфера должен быть не меньше, чем максимальный размер базы, хотя вероятность того, что в процессе дампа изменятся все данные мала.

В любом случае, тут всё достаточно условно, и требует тестирования и мониторинга для подбора оптимальных настроек.

Приблизительынй пример расчёта.

Проверяем празмер базы в памяти:

Создаём дамп:

Проверяем размер файла RBD:

Сейчас база в памяти всего 830 мб, но вообще у нас лимит задан в % от общей памяти машины:

Т.е. в принципе база может расти до ~16 ГБ (у сервера 32 GB), после создания дампа — он будет 7-8 гиг.

Теперь надо прикинуть время на выполнение синхронизации — проверим скорость передачи, и зная максимальный размер файла дампа — узнаем время.

Для проверки скорости используем iperf — устанавливаем на Мастер и Слейв хостах:

Находим IP мастера, и на нём запускаем iperf в режиме сервера:

Позже наткнулся на redis-cli --latency -h <Redis IP> -p <Redis port>

С хоста Слейва запускаем тест:

4.90 Gbits/sec — 625 MBytes/sec.

Учитывая, что максимальный размер дампа у нас будет 7 GB, и используем калькулятор тут>>> — получаем 13 секунд.

А теперь используя --stat можно проверить — как много ключей добавляется за 1 секунду:

530178 — 530407 == 229 ключей за секунду.

Либо можно использовать Prometheus и redis-exporter, а затем сделать выборку по SET-запросам, т.к. основной массив данных будет в них, используя запрос вида:

irate(redis_commands_total{instance="production.bttrm-production-console",job="redis-exporter-cluster",cmd="set"}[1m])

И размеры ключей:

229 ключей по 4.5 MB == 1 GB.

Но — такой вариант расчёта ОЧЕНЬ приблизительный, т.к. считаем ключи в обычном режиме работы.

Во время пиковых нагрузок операций может быть в 10 раз больше, соответственно и сам буфер будет забиваться быстрее.

Ссылки по теме

• Redis Clients Handling
• Client Buffers-Before taking Redis in production check this!
• Top Redis Headaches for Devops – Replication Buffer
• Redis latency problems troubleshooting
• The Endless Redis Replication Loop: What, Why and How to Solve It (slave-output-buffer-throttling не была включена в Redis, но пост интересный)
• 6 Crucial Redis Monitoring Metrics You Need To Watch
• How to collect Redis metrics
• How to Benchmark the Performance of a Redis Server
• Some interesting redis-cli commands and usages