Https://Github.Com/Erlang/Otp/Blob/OTP-27.1/Lib/Kernel/Src/Logger_h_common.Erl#L174 Https://Github.Com/Erlang/Otp/Blob/OTP-27.1/Lib/Kernel/Src/Logger_olp.Erl#L76 15 лет назад меня попросили посмотреть, почему кролик отваливается, не

работает и сжирая весь процессор и память падает.

Я нашел эту проблему и она никуда не делась.

Неужели в OTP настолько не пересекаются с высокими нагрузками?

мы пересекаемся

его используют в таких командах где не считают процессорное время и память

что нам использовать?

к чему эта нелепость. Когда данные перестают утекать, неважно сколько у тебя памяти и процессора

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

Настроить handler так, чтоб он не уходил в sync или drop

Достаточно устроить тысячу крешей в секунду с большими бинарями в стейте

а можешь поточнее описать, в чём проблема? Я в этом коде вижу: * потенциально долгое форматирование делается в контексте клиента * опциями можно ограничить размер распечатанного лога (опять же в контексте клиента) * в зависимости от глобального флага в гипотетически бесплатном хранилище (persistent_term) логирование может слегка притормозить клиентский процесс * на каждом сообщении логгер проверяет размер своего ящика и может поменять режим логирования * все пределы (`sync_mode_qlen`, drop_mode_qlen, `flush_qlen`) настраиваются * до синглтона долетают небольшие бинари, да и то если очередь не переполнена > устроить тысячу крешей в секунду с большими бинарями в стейте это может ударить по SASL и супервизору, но не должно сильно ударить по логгеру

Форматирование убивает

какие параметры по глубине и максимальному размеру записи лога?

вот тут я не понял, можешь как для танкистов?

отключай логи

могу! https://www.erlang.org/docs/26/apps/kernel/logger_chapter.html#message-queue-length

понял!

вот тут интересное: If sync_mode_qlen is set to the same value as drop_mode_qlen, synchronous mode is disabled. That is, the handler always runs in asynchronous mode, unless dropping or flushing is invoked. и у этой палки два конца: 1) если sync выключен, дроп запредельный и много логов, то они будут копиться в очереди хэндлера; 2) если sync включен, то ты блочишь процесс, который что-то логирует, и можешь получить распухшую очередь уже в нём. короч, сильно завсит от приложения и от того, насколько важны логи

куда ни кинь — всюду клин. если не успеваем логи, то без разницы в каком месте, или та или другая очередь все равно завалит систему.

flush_qlen The handler process increases its priority during the flush loop to make sure that no new events are received during the operation

Звучит как-то фаталистически

не обязательно. Учитывая, что эрланг из коробки очень говорлив, логи происходят большим всплеском, когда что-то крешится. Соответственно в этот момент они просто избыточны

не, ну значит нам надо ещё одно ядро с процессом отдельно и логи слать туда в сыром виде. не? насчет крешей, да, я считаю что let it crash на проде надо оставлять для самых нереальных случаев. если у нас такая нагрузка, что на форматирование не хватает процессора, то как минимум основных 20% случаев надо в обработчик