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

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

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

Проблема в том::

Я использую клиент для генерации событий MMS со значениями по умолчанию. Этот клиент (на Java) может отправлять большое количество событий в нескольких ПОТОКАХ.

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

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

Выводы, к которым я пришел, следующие::

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

  2. Очень маловероятное состояние мертвой блокировки.

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

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


logging freeze erlang otp
person Arunmu    schedule 29.08.2010    source источник
comment
Я попытался запустить свое приложение на 64-разрядной версии Erlang 14A ... но все еще сталкиваюсь с той же проблемой :( И то, что я на самом деле регистрирую, - это время и некоторые дополнительные сведения о событиях, которые были успешно обработаны моим приложением ... что выходит быть 3/4 полной строки.Мне нужны эти журналы, так как мой внешний скрипт будет использовать информацию из журналов для отображения количества успешных событий за определенный период времени.. До сих пор мой error_logger только зависал, но никогда не падал. Если он когда-нибудь выйдет из строя, это приведет к остановке всего моего приложения ??   -  person Arunmu    schedule 22.09.2010

Ответы (2)


arrow_upward
2
arrow_downward

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

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

На заметку: не должно быть проблем с несколькими потоками, выполняющими вызовы Erlang.

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

person Daniel Luna    schedule 01.09.2010
comment
Мне нужен форматированный вывод в журнале, поскольку я анализирую его, чтобы отображать количество успешных событий и их среднее время отклика, но не в режиме реального времени. Разве использование io:format для печати сообщений журнала в оболочке не снизит производительность? И в моем приложении я запускаю виртуальную машину Erlang в качестве демона. - person Arunmu; 01.09.2010
comment
И спасибо за ваш ответ, Даниил. :) - person Arunmu; 01.09.2010
comment
Печать io:format, конечно же, не будет отображаться, если вы запускаете виртуальную машину erlang в качестве демона. Если вы не пишете в файл, конечно. io: формат (Fd, Txt, Args). Я бы рекомендовал использовать регистратор ошибок, а не использовать io:format. У него есть множество приятных свойств, которые вам понадобятся, когда ваша система немного вырастет. - person Daniel Luna; 02.09.2010

arrow_upward
2
arrow_downward

Какую версию Эрланга вы используете? До 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) ]
person archaelus    schedule 30.08.2010
comment
Большое спасибо архаэлю. Я изучу больше вашего решения (решений). - person Arunmu; 31.08.2010