В systemd 257.9 на Debian 13 с ядром Linux 6.12.57+deb13-amd64 всплыла проблема с systemd-journald. Журнал пишет на диск настолько неэффективно, что виртуальная машина упирается в ~50 IOPS, хотя в секунду приходит всего две строки лога. Ожидаемое поведение — чтобы запись в journald была хотя бы в одном порядке величины с записью в syslog. По факту — диск молотит постоянно.
Воспроизводится это так: journald работает в режиме записи на жёсткий диск, файловая система XFS, а в лог непрерывно падают записи от haproxy — в отчёте показан поток из GET-запросов каждые две секунды. Наблюдение за IO-трафиком виртуальной машины показывает, что нагрузка на диск остаётся даже после того, как отработали механизмы ядра по объединению и отложенной записи. То есть дело не в погрешности подсчёта, а в самом journald.
Автор репорта ссылается на старый баг #15292, который закрыли без внятной причины. Тогда отговоркой было «iotop не точен». Допустим, iotop действительно врёт до того, как ОС объединит записи, но здесь трафик виден уже после всех ядерных механизмов. Так что «ядро создаёт кучу IOPS» — не объяснение. Медленный именно journald.
Отдельно жалуются на формат хранения. Journald использует крайне неэкономную структуру: файлы журнала занимают в несколько раз больше места, чем реально записанные в них данные. А ещё автор заявляет, что не раз видел повреждение журнала после некорректной перезагрузки — так что формат не такой уж надёжный. Выходит, systemd-journald одновременно и медленный, и расточительный, и с сомнительной устойчивостью к сбоям.