Стоит RabbitMQ, обслуживает порядка 5-6 источников и 4-5 потребителей,
т.е. совсем немного.
Поток сообщений небольшой: несколько штук в секунду максимум.

Иногда потребители не успевают разгрести сообщения и очередь сообщенй
растет до 5000, но позже она тоже рассасывается.
В целом, всё не страшно, но иногда RabbitMQ начинает сходить с ума.
Выражается это в отжирании 20 гигабайт памяти из которых 5 в оперативке.

Зашел на консоль сервера, нашел крысу: ей оказался процесс,
зарегистрированный как error_logger.
Его статистика по process_info(Logger, memory) показала все утерянные
20 гигабайт:

(rabbit@web1)52> Processes = processes().
(rabbit@web1)52> Logger = lists:nth(3, Processes).
(rabbit@web1)52> process_info(Logger, [memory, current_function, message_queue_len, registered]).
[{memory,20432997816},
{current_function,{io_lib_pretty,pp_binary,4}},
{message_queue_len,5280},
{registered_name,error_logger}]

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

За полчаса отладки он не считал из своего инбокса ни одного сообщения
(эрланговского), причем инбокс за это время рос. Отчет по current_function показал, что он залип в pp_binary.

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

(rabbit@web1)52> exit(Logger, kill).

После этого эрланг отожрал 100%+ CPU (ядро то не одно), и консоль больше не реагировала. Потом уже возникло предположение,
что он не завис, а просто память очищал и поэтому был слегка занят.

Версия эрланга: R12B.

Из неприятного:

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


• неясно, что происходило после прибивания логгера. То ли всё повисло, то ли просто зачищались десятки гигабайт памяти. Сам раббит при этом умещался где-то в 20 мегабайт.

Из очень приятного:

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


• В то время как сбойный процесс отожрал всю память и предательски приближался к порогу OOM, сожрал весь CPU, клиенты не сбрасывались, а исправно обслуживались. Это очень радует.