Comments 5
Извините, но я запутался:
Так кто больше нагружает CPU, синхронный или асинхронный?
У асинхронных логгеров есть другая проблема — в случае креша приложения, информация асинхронном логе может пропасть, т.е. как раз самая важная причина креша будет недоступна.
Внимательный читатель наверняка предложит полностью перейти на синхронные логгеры. Почему бы и нет? У синхронных логгеров есть неприятность – они сильно нагружают cpu. Например, в моем случае с асинхронным логгером загрузка cpu ~100% (по данным утилиты top), а в синхронном варианте порядка 10-20%. Если асинхронных логгеров будет больше, то и загрузка cpu значительно поднимется.
Так кто больше нагружает CPU, синхронный или асинхронный?
У асинхронных логгеров есть другая проблема — в случае креша приложения, информация асинхронном логе может пропасть, т.е. как раз самая важная причина креша будет недоступна.
да, вы правы.
Спасибо, что заметили и сообщили :)
И да, асинхронный логгер действительно может потерять данные. Все, что лежит в очереди, может пропасть.
Спасибо, что заметили и сообщили :)
И да, асинхронный логгер действительно может потерять данные. Все, что лежит в очереди, может пропасть.
Насколько я знаю, с помощью механизма UncaughtExceptionHandler можно обработать лог ивенты которые ещё находятся в очереди в момент возникновения креша. В этом обработчике нужно завершить работу логгера используя блокирующий вызов LoggerContext.stop(), в который даст возможность апендерам записать все ивенты в файл или базу с определенным таймаутом и дальше заверить работу приложения.
Ну обычно приложения всё-таки стараются писать так, чтобы они не падали от любого эксепшена, а креши бывают жёсткие, так что ничего пикнуть не успевает. И часто последние строчки в логах бывают очень важны. Классический пример — OOM убийство, когда по логам можно понять, где примерно всё случилось. Ну и всякие ребуты железа, убийство процессов и т.д.
Sign up to leave a comment.
Асинхронное логирование с log4j для любознательных