У RabbitMQ есть два порога, о которых вспоминают после первой остановки системы: по памяти и по свободному месту на диске. Дошёл до любого из них, и брокер перестаёт принимать сообщения. Калькулятор считает оба порога под ваш сервер и выдаёт файл настроек, запуск в Docker и команды.
Файл настроек действует после перезапуска брокера. Команды из третьего блока меняют пороги сразу, но до следующего перезапуска, поэтому нужны оба шага.
Включите JavaScript, чтобы увидеть расчёт.
Пороги без перезапуска, пользователь для RX, учётка на чтение для мониторинга и проверка результата.
Вместо паролей в командах стоит CHANGE_ME. Замените на свои, латиницей и цифрами: мы проверили, что с русскими буквами в пароле RabbitMQ 3.13 не запускается и контейнер уходит в бесконечный перезапуск. Встроенного пользователя guest не оставляйте: его пароль знают все.
Брокер редко настраивают: он работает из коробки, пока в очередях пусто. Проблемы начинаются в день, когда обработчик остановился и сообщения начали копиться.
Когда брокер занимает память до порога, он блокирует всех, кто публикует сообщения. Для Directum RX это остановка: задания не уходят, сервисы пишут о недоступности брокера. По умолчанию порог равен 40 % памяти в версии 3.13 и 60 % в 4.x. Мы ставим 60 % от памяти, отведённой брокеру: остальное нужно сборщику мусора Erlang, который на пике занимает заметно больше рабочего объёма.
По нашему замеру RabbitMQ 3.13 в Docker с лимитом 400 МБ посчитал порог от памяти сервера и получил 7 ГБ. В такой конфигурации тревога по памяти не сработает никогда: контейнер убьют по лимиту раньше, и брокер перезапустится с потерей соединений. Поэтому в файле настроек явно задан параметр total_memory_available_override_value: он сообщает брокеру, сколько памяти у него на самом деле.
По умолчанию порог 50 МБ: брокер остановит приём, когда на диске почти ничего не осталось, и к этому моменту плохо уже всем. Мы ставим порог в полтора раза больше порога памяти и не меньше 2 ГБ: при нехватке памяти брокер сбрасывает сообщения на диск, и место под это должно быть. Том должен быть в несколько раз больше порога. Том 2 ГБ при пороге 2 ГБ неработоспособен: тревога не снимется даже на пустом диске. Мы видели, как так легли четыре стенда разом.
RabbitMQ хранит данные в каталоге с именем узла, а имя узла берёт из имени хоста. У контейнера без ключа --hostname имя случайное и меняется при пересоздании. Брокер после этого стартует пустым: без очередей, пользователей и прав, хотя том на месте. Поэтому имя хоста в команде запуска задано явно.
Сервисы RX при каждом запуске объявляют служебные очереди с уникальным идентификатором в имени. После перезапуска сервиса старая очередь остаётся. За месяцы их набираются тысячи, брокер тратит на них память, а в кластере ещё и время на согласование. Политика expires удаляет очередь, которой никто не пользовался сутки. Работающий сервис обращается к своей очереди и сбрасывает таймер, поэтому живые очереди политика не трогает. Проверяли на кластере: число очередей упало с 3207 до 597.
Параметр cluster_partition_handling = pause_minority останавливает узел, который потерял связь с большинством. Без него при разрыве сети обе половины продолжают принимать сообщения и расходятся. Три узла на одном сервере отказоустойчивости не дают: кластер имеет смысл только на трёх разных серверах. Очереди RX в кластере должны быть кворумными, это задаётся в настройках самой системы.
Каждое соединение и каждая очередь занимают файловый дескриптор. Значения по умолчанию 1024 мало, документация RabbitMQ требует не меньше 65536. В контейнере это ключ --ulimit, у службы параметр LimitNOFILE.
Чего калькулятор не делает: не подбирает память под ваш поток сообщений. Два гигабайта хватает большинству установок на одном сервере, пока обработчики успевают. Если очереди копятся, растить память бесполезно: нужно чинить обработчик. Накопление показывает rxdoctor.
Брокер пишет про alarm или отклоняет подключение. Справочник ошибок