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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 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.

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

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

Также убедитесь, что вы работаете в версии RabbitMQ, которая поддерживает настройку vm_memory_high_watermark - в идеале вы должны работать с последней стабильной версией.

Answer 2

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

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

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