Одна строка лога вызывает до 110 КБ записи на диск в systemd-journald¶
7.0/10
Открытый в репозитории systemd issue #40262 сообщает, что одна строка лога может вызывать 49 КБ+ записи на диск на ext4 и 110 КБ+ на btrfs при работе systemd-journald. Это демонстрирует серьёзную неэффективность хранения журнала в популярной системе логирования, что увеличивает износ SSD и нагрузку на диск. Проблема также вызвала дискуссию о том, что journald практически нельзя отфильтровать по источнику сообщений, а единственные штатные ограничения — по уровню серьёзности или переход на перенаправление в rsyslog. Некоторые пользователи предлагают использовать journald только как маршрутизатор, не сохраняя логи в нём. В обсуждении отмечают, что индексирование journald медленное и не даёт контроля над «болтливыми» подсистемами.
Контекст¶
systemd-journald — это системная служба журналирования systemd, которая хранит логи в бинарном журнале с индексацией. Размер журнала можно ограничить через параметры в файле /etc/systemd/journald.conf, например SystemMaxUse, а для очистки используются команды вроде journalctl --vacuum-time и --vacuum-size. Однако фильтрация записей по отдельным источникам ограничена, что отмечают пользователи; это важно для понимания проблемы, когда одна строка лога вызывает десятки килобайт записи на диск.
Влияние¶
Для администраторов, использующих постоянное хранение journald на ext4 или btrfs, каждая строка лога может приводить к десяткам и сотням килобайт дисковых операций, ускоряя износ SSD и увеличивая задержки ввода-вывода; поскольку фильтрация по отдельным идентификаторам ограничена, подавить проблемные драйверы можно только на уровне ядра или через перенаправление во внешний сборщик логов.
Обсуждение¶
В комментариях пользователи жалуются на невозможность нормальной фильтрации journald: доступно только ограничение по severity или переключение на непостоянное хранение с пересылкой в rsyslog. Один из участников называет journald худшей частью экосистемы systemd и рекомендует использовать его лишь как роутер, а другой после оценки размера журнала рассматривает переход на Devuan; также есть критика, что попытка повторить Windows Event Log провалилась.