Плохая производительность RabbitMQ

Мы столкнулись с низкой производительностью в наших кластерах RabbitMQ. Даже при простое.

После установки плагина Rabbitmq-top мы видим множество процессов с очень высокими сокращениями/ сек. 100к и больше!

Вопросы:

  • Что это значит?
  • Как это контролировать?
  • Что может быть причиной такой медлительности без каких-либо ошибок?

Примечания:

  • Наши кластеры работают на Kubernetes 1.15.11
  • Мы выделили 3 узла, каждый с ограничениями по 8 ЦП и 8 ГБ. Установите vm_watermark на 7G. Фактическое использование составляет ~ 1,5 ЦП и 1 ГБ ОЗУ.
  • КроликMQ 3.8.2. Эрланг 22.1
  • У нас не так много потребителей и производителей. Медлительность также в довольно бездействующей среде
  • rabbitmqctl status очень медленно возвращает данные (иногда 2 минуты), но не показывает никаких ошибок

rabbitmq rabbitmqctl erlang
person Eldad Assis    schedule 12.06.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

  1. Конфигурация времени выполнения RabbitMQ (Erlang) по умолчанию (с использованием рулевой диаграммы bitnami) назначает только один расписание. Это хорошо для некоторых простых приложений с несколькими одновременными подключениями. Производственный уровень с тысячами подключений должен использовать гораздо больше планировщиков. Увеличение числа планировщиков с 1 до 8 значительно увеличило пропускную способность.
  2. Наш мониторинг забивал RabbitMQ большим количеством запросов в секунду (около 100/сек). Мониторинг попадает в aliveness-test, который создает соединение, объявляет очередь (не зеркально), публикует сообщение, а затем использует это сообщение. Отключение мониторинга резко снизило нагрузку. Загрузка ЦП снизилась на 80 - 90 %, а уменьшение производительности в секунду также сократилось примерно на 90 %.

Ссылки

Производительность:

Мониторинг:

person Eldad Assis    schedule 12.06.2020