Проблемы с RabbitMQ: зависший error_logger.
Max Lapshin
т.е. совсем немного.
Поток сообщений небольшой: несколько штук в секунду максимум.
Иногда потребители не успевают разгрести сообщения и очередь сообщенй
растет до 5000, но позже она тоже рассасывается.
В целом, всё не страшно, но иногда RabbitMQ начинает сходить с ума.
Выражается это в отжирании 20 гигабайт памяти из которых 5 в оперативке.
Зашел на консоль сервера, нашел крысу: ей оказался процесс,
зарегистрированный как error_logger.
Его статистика по process_info(Logger, memory) показала все утерянные
20 гигабайт.
За полчаса отладки он не считал из своего инбокса ни одного сообщения
(эрланговского), причем инбокс за это время рос.
Отчет по current_function показал, что он залип в pp_binary.
Порадовало что получилось оперативно найти логгера, попросту зависшего
в чём-то. После попыток выяснить что с ним такое,
было решено прибить его:
exit(Logger, kill).
После этого эрланг отожрал 100%+ CPU (ядро то не одно), и консоль
больше не реагировала. Потом уже возникло предположение,
что он не завис, а просто память очищал и поэтому был слегка занят.
Версия эрланга: R12B
Вопросы такие:
1) Это нормально для error_logger-а отжирать по 20 гиг?
2) Правильное ли поведение — пристреливать заразу?
3) Как-нибудь можно выяснить, какие именно данные привели к такому поведению?
4) Правильно ли я предположил, что супервизор перезапустит
error_logger и просто нода была занята очисткой памяти?
Peter Lemenkov
2009/9/15 Max Lapshin <max.l...@gmail.com>:
> Зашел на консоль сервера, нашел крысу: ей оказался процесс,
> зарегистрированный как error_logger.
> Его статистика по process_info(Logger, memory) показала все утерянные
> 20 гигабайт.
С error_logger могут возникать такие гадости, т.к., в отличие от
других компонентов, он не масштабируется. Сам недавно про такое узнал.
> Вопросы такие:
>
> 1) Это нормально для error_logger-а отжирать по 20 гиг?
Они подменили, видимо, error_logger своей реализацией (это нормально -
так делают), да вот своя реализация видимо заглючила. Он завис, а
сообщения продолжали поступать на него со всех нод - так-что 20 гигов
накопить вполне можно было.
> 4) Правильно ли я предположил, что супервизор перезапустит
> error_logger и просто нода была занята очисткой памяти?
Ну если в свапе было гигов 20, то его очистка вполне могла привести к
большому la.
--
With best regards, Peter Lemenkov.
Max Lapshin
> так делают), да вот своя реализация видимо заглючила. Он завис, а
> сообщения продолжали поступать на него со всех нод - так-что 20 гигов
> накопить вполне можно было.
>
О, спасибо, погляжу. Но там другая ситуация: ни одного сообщения не
было вообще получено, я смотрел на список messages.
Так что предположительно, он вошел где-то в нехвостовую рекурсию или
просто начал накапливать данные в буфере, переживающем
tail call и так жрал память.
>> 4) Правильно ли я предположил, что супервизор перезапустит
>> error_logger и просто нода была занята очисткой памяти?
>
> Ну если в свапе было гигов 20, то его очистка вполне могла привести к
> большому la.
Да, наверное зря мы его через 5 минут рестартнули.
Gleb Peregud
> exit(Logger, kill).
>
> После этого эрланг отожрал 100%+ CPU (ядро то не одно), и консоль
> больше не реагировала. Потом уже возникло предположение,
> что он не завис, а просто память очищал и поэтому был слегка занят.
Если был включен SASL, то вероятно, что после того как error_logger
был убит SASL решил выписать error report насчёт данного краша и из-за
форматирования такого огромного количества данных вся система подвисла
с 100% использованием cpu
Max Lapshin
> был убит SASL решил выписать error report насчёт данного краша и из-за
> форматирования такого огромного количества данных вся система подвисла
> с 100% использованием cpu
А кому выписать? Ведь error_logger-а больше нет.
И, кстати, вы наверное правы: стектрейс у такого процесса будет чудовищным.