2 мин чтения
Коротко
Проблему избыточных записей systemd-journald обсуждали годами, но её последствия легко пропустить: обычное журналирование способно создавать заметную нагрузку на накопитель. Разбираю, почему это происходит и чем приходится платить за отключение постоянных логов.
Логи могут незаметно стать одним из самых активных потребителей SSD. В systemd-journald спустя шесть лет признали проблему: служба создаёт избыточные записи на накопитель из-за write amplification — фактический объём записи оказывается больше объёма самих журналов.
Проблему начали обсуждать ещё в 2020 году. В одном из тестов сообщалось, что при появлении около 500 МБ данных journald записывал на SSD примерно 700 МБ. На обычном компьютере это может выглядеть мелочью, но для систем с eMMC, NAND, MicroSD или дисками, которым важен ресурс записи, уже становится неприятным сигналом.
Причина связана не только с количеством сообщений. journald работает с файлами журналов через mmap, а при определённых сценариях, включая нагрузку в cgroup и работу с loop-устройствами, записи могут порождать дополнительный обмен с диском. В итоге мониторинг, который должен помогать диагностировать систему, сам становится источником нагрузки.
И здесь важен не сам факт старого бага, а модель поддержки. Первоначальное сообщение, по данным источника, сочли недостаточно пригодным для действий и закрыли как not actionable. Спустя годы новые эксперименты снова показали проблему — уже на сценариях, где избыточная запись может быть особенно заметна.
Ограничение простого обходного пути очевидно: в обсуждении советуют настроить Storage=volatile в /etc/systemd/journald.conf. Это переносит журналы в оперативную память и снижает запись на диск, но после перезагрузки постоянных логов не будет. Кроме того, часть возможностей просмотра пользовательских журналов и разбиения данных по пользователям при таком режиме теряет смысл. Поэтому отключать дисковое журналирование вслепую на сервере тоже нельзя: ресурс SSD меняется на риск потерять данные для расследования сбоя.
Практический вывод простой: journald стоит рассматривать не как бесплатный фоновой сервис, а как потребителя дискового ресурса. Если система работает на слабом или изношенном накопителе, проверьте реальный объём записей и заранее решите, что важнее — сохранность журналов после перезагрузки или минимальная нагрузка на SSD.
Вы готовы пожертвовать постоянными логами ради ресурса накопителя, если система работает на eMMC или MicroSD? Источник: OpenNews.opennet.ru: Общая лента новостей