RabbitMQ - сколько очередей RabbitMQ может обрабатывать на одном сервере?

Я хочу знать, сколько максимальных очередей RabbitMQ может обрабатывать на одном сервере?

зависит ли это от ОЗУ? Зависит ли это от процессов erlang?

2 ответов


внутри брокера RabbitMQ нет жестких ограничений. Брокер будет использовать все доступные ресурсы (если вы не установите ограничения на некоторые из них, они называются водяные знаки в терминологии RabbitMQ).

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

есть много обсуждения использования и ограничений ресурсов RabbitMQ,

P. S. Есть правда ограничение по AMQP протокол. Они описаны в разделе 4.9 Ограничения

спецификации AMQP накладывают эти ограничения на будущие расширения AMQP или протоколы из того же формата проводного уровня:

  • количество каналов на соединение: 16-разрядный номер канала.
  • количество классов Протокола: 16-разрядный идентификатор класса.
  • количество методов на протокол класс: 16-разрядный идентификатор метода.

спецификации AMQP накладывают эти ограничения на данные:

  • максимальный размер короткой строки: 255 октетов.
  • максимальный размер длинной строки или поля таблицы: 32-bit размер.
  • максимальный размер полезной нагрузки кадра: 32-битный размер.
  • максимальный размер содержимого: 64-битный размер.

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


этот пост может помочь вам:

http://rabbitmq.1065348.n5.nabble.com/Max-messages-allowed-in-a-queue-in-RabbitMQ-td26063.html

редактировать

1) разрешены максимальные очереди в RabbitMQ?

тысячи (или даже десятки тысяч) очередей не должно быть никаких проблем вообще, хотя каждый объект (например, очереди, обмены, привязки и т. д) займет немного памяти и / или дискового пространства. По умолчанию, Erlang будет принудительное выполнение максимального количества параллельных процессов (т. е. темы) в районе 32768 IIRC. Каждая очередь управляется своей собственной процесс и каждое соединение могут привести к еще нескольким, поэтому, если вы планирование наличия очень большого количества активных очередей в одной узел (?) и используя их все одновременно, вам может понадобиться настройка аргументов эмулятора кролик передает VM, установив +P на более высокий предел.

вы также можете использовать много ГБ только с накладные расходы для каждого очередь / соединение довольно быстро, поэтому вам понадобится довольно мясистый сервер для обработки миллионов обоих. Десятки тысяч должно быть проблема вообще, если они вписываются в ОЗУ.