Уменьшите использование памяти RabbitMQ

Я пытаюсь запустить RabbitMQ на небольшой VPS (512 Мб RAM) вместе с Nginx и несколькими другими программами. Я смог без труда настроить использование памяти всего остального, но я не могу заставить RabbitMQ использовать меньшее количество ОЗУ.

Я думаю, мне нужно уменьшить количество потоков, используемых Erlang для RabbitMQ, но я не смог заставить его работать. Я также попытался установить vm_memory_high_watermark на несколько разных значений ниже значения по умолчанию (40%), даже до 5%.

Частью проблемы может быть то, что поставщик VPS (MediaTemple) позволяет мне переходить через выделенную память, поэтому при использовании бесплатного или верхнего уровня это показывает, что сервер имеет около 900 МБ.

Любые предложения по сокращению использования памяти с помощью RabbitMQ или ограничение количества потоков, которые создаст Erlang? Я считаю, что Erlang использует 30 потоков на основе флага -A30, который я видел в команде процесса.

В идеале я бы хотел использовать RabbitMQ mem ниже 100 МБ.

Edit:

С vm_memory_high_watermark установлено значение 5% (или 0,05 в конфигурационном файле), журналы RabbitMQ сообщают, что ограничение памяти RabbitMQ установлено равным 51 МБ. Я не знаю, откуда взялось 51mb. Текущая выделенная память VPS составляет 924 МБ, поэтому 5% от нее должно быть около 46 МБ.

В соответствии с htop/free, прежде чем запускать RabbitMQ, я сижу около 453 мб используемого бара, а после запуска RabbitMQ я около 650 МБ. Почти 200 мб. Может ли быть, что 200mb - это нижний предел, который RabbitMQ будет работать с?

Изменить 2

Вот несколько скриншотов ps aux и бесплатно до и после запуска RabbitMQ и графика, показывающего всплеск памяти при запуске RabbitMQ.

Изменить 3

Я также проверил без включения плагинов, и это сделало очень мало различий. Кажется, что плагины, которые у меня были (управление и его предпосылки), добавили только около 8 мб использования ram.

Изменить 4

У меня больше нет этого сервера для тестирования, однако есть настройка conf delegate_count, для которой установлено значение по умолчанию 16. Насколько я знаю, это порождает 16 sup-procs для rabbitmq. Уменьшение этого числа на небольших серверах может помочь уменьшить объем памяти. Не знаю, работает ли это на самом деле или как это влияет на производительность, но это что-то попробовать.

Ответ 1

Для ограничения использования памяти в RabbitMQ используется vm_memory_high_watermark. Вы сказали:

Я также попытался установить vm_memory_high_watermark для нескольких разные значения ниже значения по умолчанию ( 40%), даже до 5%.

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

=INFO REPORT==== 29-Oct-2009::15:43:27 ===
Memory limit set to 2048MB.

Вам нужно настроить ограничение памяти по мере необходимости. Кролик может видеть, что ваша система имеет намного больше ОЗУ, чем вы думаете, если вы работаете в среде VPS.

Иногда Кролик не может определить, в какой системе вы находитесь, и использует 1GB в качестве базовой точки (так что вы получаете ограничение по 410 МБ по умолчанию).

Кроме того, убедитесь, что вы используете версию RabbitMQ, поддерживающую настройку vm_memory_high_watermark - в идеале вы должны работать с последней стабильной версией.

Ответ 2

Обязательно установите соответствующее значение предварительной выборки QoS. По умолчанию, если есть клиент, сервер Rabbit отправит клиенту все сообщения, которые он имеет для этой клиентской очереди. Это приводит к широкому использованию памяти как на клиенте, так и на сервере.

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

Обратите внимание, что предложение 100 - это просто разумное место для начала - он уверен, что он побеждает бесконечность. Чтобы действительно оптимизировать этот номер, вы захотите принять во внимание сообщения/сек, которые ваш клиент может обработать, латентность вашей сети, а также то, насколько велико каждое из ваших сообщений в среднем.