Erlang / OTP frameworks error_logger зависает при довольно высокой нагрузке

Question

Мое приложение - это маршрутизатор, основанный на контенте, который будет направлять события MMS.

Я использую регистратор, который поставляется с OTP-фреймворком в режиме SASL " error_logger "

Вопрос: ::

Я использую клиент для создания MMS-событий со значениями по умолчанию. Этот клиент (на Java) имеет возможность отправлять большое количество событий в нескольких THREADS

Я отправляю 100 событий в 10 потоках (каждый поток отправляет 10 событий MMS) на мой маршрутизатор, записанный в erlang / OTP.

Проблема в том, что когда мой маршрутизатор получает такую ​​высокую нагрузку, мой Logger зависает , т.е. он перестает обновлять мой файл журнала. Но маршрутизатор все еще может маршрутизировать события.

Выводы, которые я сделал, таковы:

1) Проблема планирования в эрланге при получении такой высокой загрузки событий (отдельный процесс эрланга для каждого события).

2) Очень маловероятное состояние тупика.

3) Возможно, из-за отправки событий в нескольких потоках, а не из-за их последовательной отправки. Но я предполагаю, что маршрутизатор будет подключен к нескольким блокам поставщика услуг, поэтому я подумал об отправке событий в потоках.

Кто-нибудь может помочь mw в демистификации проблемы?

Answer 1

Какую версию Erlang вы используете? До R14A (может быть R13B4?) Было снижение производительности, когда вы вызывали выборочный прием, когда очередь сообщений содержала много сообщений. Такое поведение означало, что в процессе, который получает много сообщений (error_logger является каноническим примером), если он едва поспевает за нагрузкой, то небольшой скачок нагрузки может привести к резкому увеличению стоимости обработки и оставаться там как стоимость новой обработки была выше, чем мог выдержать процесс. Эта проблема была решена в R14A.

Во-вторых - почему вы отправляете большое количество событий / звонков / журналов в текстовый логгер? Форматирование строк для вывода в читаемый человеком файл журнала намного дороже, чем, например, использование двоичного файла disk_log. Сокращение затрат на ведение журнала поможет, но уменьшение объема журналов поможет еще больше. Возможно, выясните, почему вам нужно регистрировать эти вещи, и посмотрите, не можете ли вы записать их другим (менее дорогим) способом.

Проблемы с error_logger часто являются признаками некоторых других проблем с перегрузкой. Попробуйте найти размеры очереди сообщений для всех ваших процессов, когда возникнет эта проблема, и посмотрите, выполняется ли резервное копирование чего-то еще. Следующий шеллкод erlang может помочь:

[ { P, element(2, process_info(P, message_queue_len)) } 
  || P <- erlang:processes(), is_process_alive(P) ]

Answer 2

У вас уже есть хороший ответ, но я добавлю к обсуждению.

По умолчанию error_logger использует кэшированные операции записи на диск.Таким образом, одна возможность состоит в том, что вы действительно не замечаете этого при низкой нагрузке, но при высокой нагрузке ваши записи на некоторое время застряли в кеше.

Примечание: не должно быть проблем с несколькимипотоки обращаются к Erlang.

Еще один способ проверить это - добавить собственный логгер в error_logger и посмотреть, что произойдет.Возможно печать на оболочке или что-то еще, что «быстро».