Почему совет «отключить journald ради скорости диска» устарел

MAATRIX

Заходите на форум или в старый чек-лист по тюнингу Linux-сервера — и почти наверняка встретите совет «отключите journald, он грузит диск и жрёт CPU». Совет живёт годами, кочует из статьи в статью и до сих пор звучит убедительно: логи действительно занимают место, писать их действительно нужно куда-то на диск. Проблема в том, что этот совет родом из другой эпохи — вращающихся дисков и ранних версий journald, — и на современном железе он не столько ускоряет сервер, сколько лишает вас единственного источника правды в момент, когда сервер уже упал и вы пытаетесь понять почему.

Откуда взялся совет: вращающиеся диски и ранний journald

Systemd и journald появились в начале 2010-х как замена классической связке syslog/rsyslog. Идея была разумной: единый бинарный журнал, структурированные поля, встроенная индексация вместо grep по текстовым файлам. Но у ранних реализаций были реальные проблемы, из которых и вырос совет «просто отключи».

Во-первых, вращающийся диск (HDD) физически плохо справляется с потоком мелких синхронных записей. journald на дефолтных настройках периодически делает fsync, чтобы не терять записи при сбое питания — на HDD с его позиционированием головки это ощутимая задержка на каждую операцию, заметная под нагрузочным потоком логов (веб-сервер с большим трафиком, verbose-логирование приложения).

Во-вторых, ранние версии journald были прожорливее по CPU при индексации и ротации, а поведение rate limiting и лимитов по умолчанию было настроено не всегда разумно — из коробки журнал мог либо копить слишком много, либо агрессивно резать поток сообщений, и разобраться в этом было не так просто, как в привычном logrotate для текстовых файлов.

В-третьих, на серверах с маленьким диском (типичная конфигурация VPS десятилетие назад) бинарный журнал без внятных лимитов действительно мог съесть заметную долю свободного места, а администраторы не знали о параметрах SystemMaxUse и RuntimeMaxUse — документация по journald тогда была куда менее подробной.

В сумме получалось: медленный диск + не всегда удачные дефолты + непрозрачные настройки = совет «выключи Storage, поставь none, и всё станет быстрее». Совет решал реальную проблему конкретного железа и конкретной версии софта, а не journald как концепции.

Что изменилось: SSD/NVMe и повзрослевший journald

К концу 2020-х годов оба условия, породивших совет, изменились кардинально.

Диск. Подавляющее большинство арендуемых VPS и выделенных серверов сегодня работают на SSD, а всё больше — на NVMe. Латентность случайной записи на NVMe ниже, чем на HDD, на порядки, а сама природа мелких синхронных записей (в том числе fsync) для флеш-памяти не так болезненна, как для механики с движущейся головкой. Поток записи журнала, который раньше вызывал заметные просадки на вращающемся диске, на современном SSD/NVMe чаще всего теряется в фоновом шуме остальной нагрузки на диск и практически не ощущается на latency других процессов.

journald. За годы развития у systemd появился гораздо более прозрачный и предсказуемый набор настроек хранения логов: явные лимиты по объёму (SystemMaxUse, RuntimeMaxUse), по времени хранения (MaxRetentionSec), по размеру отдельного файла (SystemMaxFileSize), сжатие записей (Compress), встроенный rate limiting с настраиваемым окном и порогом. Это ровно тот функционал, отсутствие управляемости которым раньше подталкивало людей к «просто выключить». Сейчас управлять ростом журнала можно тонко, не теряя сам факт логирования.

Итог: физическая причина совета (медленный диск) в массе своей исчезла вместе с переходом на SSD/NVMe, а организационная причина (нет управляемых лимитов) исчезла вместе с развитием journald. Совет продолжает жить по инерции — потому что старые статьи не удаляются, а «работает — не трогай» звучит убедительно даже когда контекст, в котором это работало, давно сменился.

Чего вы реально лишаетесь, отключив journald

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

Когда Storage=none или сервис journald полностью замаскирован (systemctl mask systemd-journald), вы теряете:

• Единый источник логов ядра и systemd-юнитов. Сообщения ядра (OOM killer, ошибки драйверов, аппаратные предупреждения), логи сбоев служб при старте, вывод systemd о том, почему юнит не поднялся, — всё это по умолчанию идёт в journald. Без него нет dmesg-истории после ребута и не видно, что происходило с сервисом в момент падения, если он не пишет собственный файловый лог.
• Корреляцию по времени между разными источниками. journald сшивает сообщения от ядра, systemd и сервисов в единую хронологию с точными метками. При инциденте это экономит десятки минут: не нужно сверять часы разных лог-файлов вручную.
• Диагностику падения самого сервера. Бинарный журнал с fsync на критичных записях переживает жёсткую перезагрузку и позволяет открыть journalctl -b -1 и увидеть последние секунды жизни системы перед крахом. Текстовые логи приложений часто теряют последние строки из-за собственной буферизации; journald в этом смысле надёжнее по конструкции.
• Быстрый структурированный поиск. journalctl -u nginx --since "1 hour ago" -p err — секундная команда. Без journald тот же результат придётся собирать через grep по текстовым логам разных сервисов, заранее зная, где какой лежит и в каком формате.

Отдельно стоит сказать про инциденты безопасности. Если журнал отключён, у вас нет системного лога аутентификации и авторизации в удобном виде, нет истории запуска процессов через systemd, нет площадки для последующего аудита — картина по атаке собирается по обрывкам, если вообще собирается. Про то, как читать логи и искать причину сбоя, когда они всё-таки есть, у нас есть отдельный разбор — как читать логи и находить причину сбоя.

Экономия на диске от отключения journald на современном SSD — единицы, редко больше пары процентов IOPS в пиковых сценариях. Цена ошибки при разборе инцидента без логов — часы или дни расследования, а иногда и невозможность его завершить. Соотношение риска и выгоды за прошедшее десятилетие сместилось радикально не в пользу отключения.

Как настроить journald правильно вместо отключения

Правильная реакция на «journald ест диск» — не выключить журналирование, а поставить журналу разумные границы. Основной конфиг — /etc/systemd/journald.conf (и /etc/systemd/journald.conf.d/*.conf для override-фрагментов, что удобнее при последующих обновлениях).

Базовый набор лимитов, который стоит выставить на большинстве серверов:

[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=500M
SystemKeepFree=1G
SystemMaxFileSize=50M
MaxRetentionSec=1month
MaxFileSec=1week
RateLimitIntervalSec=30s
RateLimitBurst=10000

Что делает каждый параметр:

• SystemMaxUse — жёсткий потолок суммарного объёма журнала на диске. journald сам будет удалять старые записи, не давая журналу вырасти больше указанного. Это прямой аналог того, зачем раньше «отключали» журнал — только без потери логирования как такового.
• SystemKeepFree — сколько места на файловой системе journald обязан оставлять свободным независимо от SystemMaxUse. Страховка на случай, если диск и так почти заполнен другими данными.
• SystemMaxFileSize — размер одного файла журнала до ротации на новый. Влияет на то, насколько гранулярно можно удалять старые куски.
• MaxRetentionSec — максимальный возраст записей независимо от объёма: даже если лимит по месту не выбран, записи старше указанного срока будут вычищены.
• Compress — сжатие крупных записей журнала «на лету», снижает фактический объём на диске почти без ощутимой нагрузки на CPU при чтении/записи.
• RateLimitIntervalSec / RateLimitBurst — защита от шторма логов: если один сервис вдруг начинает писать тысячи одинаковых сообщений в секунду (частый сценарий при зависшем цикле или флапающем сервисе), journald начнёт их скидывать после превышения порога в указанном окне, а не забивать диск и CPU индексацией дублей. Дефолтные значения консервативны — под конкретную нагрузку их обычно стоит поднять, а не убирать логирование целиком.

После правки конфига применяем и проверяем:

sudo systemctl restart systemd-journald
journalctl --disk-usage

Для разового освобождения места без ожидания автоматической ротации есть прямые команды:

sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-time=1month

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

Отдельно стоит проверить дефолтный rate limiting под свою нагрузку: если в момент реального инцидента (а не шторма мусорных сообщений) journald начинает резать полезные записи, это тоже потеря диагностики — просто более скрытая, чем полное отключение. journald сам подсказывает, сколько сообщений было отброшено: ищите строку Suppressed N messages в выводе journalctl, это сигнал пересмотреть RateLimitBurst для конкретного юнита через LogRateLimitIntervalSec=/LogRateLimitBurst= в его unit-файле.

Persistent vs volatile: где на самом деле хранить журнал

Один из самых частых источников путаницы — параметр Storage, у которого четыре режима, и выбор между ними куда важнее, чем сам факт «включён журнал или нет».

На практике на сервере, где важно разбирать инциденты постфактум, вариант — persistent, с явно созданным каталогом:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Если каталог /var/log/journal не создан, а Storage=auto (частый дефолт), журнал будет жить только в tmpfs и полностью исчезнет при перезагрузке — то есть именно тот случай, когда после падения сервера смотреть уже нечего, хотя журналирование формально «включено». Это отдельная и довольно частая причина, почему логов не оказывается под рукой в момент разбора инцидента — не потому что их выключили осознанно, а потому что каталог для persistent-хранения никто не создал.

Режим volatile — не антипаттерн сам по себе, а осознанный выбор для конкретных сценариев: read-only корневая файловая система, желание минимизировать циклы записи на флеш-накопитель с ограниченным ресурсом, или архитектура, где журнал целиком форвардится во внешнюю систему (например, через ForwardToSyslog=yes в связке с внешним rsyslog или прямой отправкой в централизованный сборщик), а локальная копия не нужна вообще. Если у вас несколько серверов и хочется единой картины логов, есть смысл смотреть в сторону агрегатора — например, разбор установки и эксплуатации в статье Graylog на Ubuntu: пошаговая установка или сравнение подходов к сбору логов с нескольких серверов.

Когда отключение действительно оправдано

Совет «отключить journald» неверен как универсальная рекомендация для типового сервера, но не абсолютно: есть узкий набор ситуаций, где отказ от системного логирования (или его радикальное урезание) — обоснованное инженерное решение, а не карго-культ из старых форумов:

• Embedded-системы с ограниченным ресурсом флеш-памяти. На встраиваемых устройствах с eMMC небольшого объёма, без замены накопителя в течение жизненного цикла, каждый лишний цикл записи имеет значение. Здесь Storage=volatile или полный отказ от локального журнала в пользу форвардинга по сети — оправданный компромисс: цена записи (физический износ несменного носителя) выше цены потерянной диагностики.
• Read-only корневая файловая система по архитектуре. Некоторые дистрибутивы и appliance-образы намеренно монтируют / только для чтения ради устойчивости к сбоям питания. В такой архитектуре persistent-журнал невозможен без отдельного смонтированного раздела, и volatile — не компромисс, а единственный вариант.
• Жёстко лимитированный по IOPS/трафику тарифный план, где каждая операция записи имеет цену, а сервисы и так пишут structured-логи напрямую во внешний коллектор без нужды дублировать их локально.
• Короткоживущие stateless-узлы в автоскейлинге, где сам узел не переживает дольше нескольких часов, а вся диагностика по определению строится на внешнем централизованном логировании — локальный persistent-журнал такому узлу почти ничего не даёт.

Общий признак оправданного отключения — сознательный архитектурный выбор с готовой альтернативой (внешний сборщик, физическое ограничение носителя), а не «у нас сервер немного тормозит, дай попробуем выключить логи». Если альтернативы у вас нет, а решение принимается по мотивам старой статьи про ускорение диска — вы, скорее всего, просто теряете диагностику без реальной выгоды.

Частые вопросы