мешает работе журнал ресурсы

Сообщения в журнале пропадают: сработало ограничение частоты

Журнал ограничивает частоту записей от одной службы. Превысив предел, она получает строку о подавленных сообщениях, а остальное теряется — и при разборе аварии выясняется, что самых нужных строк нет.

Вероятные причины

По порядку: сверху то, что встречается чаще.

Служба пишет слишком много сообщений

Предел по умолчанию — порядка тысячи сообщений за 30 секунд. Служба в цикле ошибок исчерпывает его мгновенно.
Ограничение задано слишком строго в общих настройках

Значения в journald.conf действуют на все службы. Заниженный предел режет журнал всей машины.
Журнал упирается в предел размера

При исчерпании места старые записи вытесняются. Внешне это похоже на подавление, но причина другая.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Кто и сколько сообщений потерял.

journalctl -b --no-pager | grep -i suppressed | tail

Сколько места занимает журнал.

journalctl --disk-usage

Действующий предел для этой службы.

systemctl show myapp.service -p LogRateLimitIntervalSec -p LogRateLimitBurst

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Служба пишет слишком много сообщений

Почему происходит: Предел по умолчанию — порядка тысячи сообщений за 30 секунд. Служба в цикле ошибок исчерпывает его мгновенно.

Как проверить

Поищите записи о подавленных сообщениях.

journalctl -b --no-pager | grep -i "suppressed" | tail -10

Как исправить

Сначала разберитесь, почему служба столько пишет: обычно это цикл ошибок. Если объём законный, поднимите предел точечно для этой службы.

sudo systemctl edit myapp.service   # [Service]\nLogRateLimitIntervalSec=30s\nLogRateLimitBurst=10000

2. Ограничение задано слишком строго в общих настройках

Почему происходит: Значения в journald.conf действуют на все службы. Заниженный предел режет журнал всей машины.

Как проверить

Посмотрите общие настройки.

grep -iE "RateLimit" /etc/systemd/journald.conf

Как исправить: Правьте общий предел осознанно: он защищает диск от заливки журналом.

3. Журнал упирается в предел размера

Почему происходит: При исчерпании места старые записи вытесняются. Внешне это похоже на подавление, но причина другая.

Как проверить

Посмотрите занятое место и пределы.

journalctl --disk-usage
grep -iE "SystemMaxUse|MaxRetentionSec" /etc/systemd/journald.conf

Как исправить: Поднимите предел размера или сократите объём записей от болтливых служб.

Пример вывода

Часть сообщений службы потеряна. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

systemd-journald[400]: Suppressed 14322 messages from myapp.service
myapp[1200]: retrying connection (attempt 4001)

Связанные ошибки

Журнал пропадает после перезагрузки journalctl не показывает записи прошлых загрузок: журнал хранится только в памяти. Как включить постоянное хранение.
start-limit-hit: служба заблокирована после серии перезапусков Состояние start-limit-hit и сообщение start request repeated too quickly: systemd перестал перезапускать службу. Как разблокировать и найти исходную причину.
No space left on device в журнале службы Нет места на устройстве: разбор по свободным блокам, по inode, по журналу systemd и по удалённым, но открытым файлам.
Suppressed N messages from unit: часть записей потеряна journald отбросил часть записей из-за ограничения частоты. Как понять, что именно потеряно, и когда предел нужно поднять.
Журнал занимает слишком много места Журнал разросся: где задаются пределы, как обрезать и почему обрезка иногда не помогает.
Cannot allocate memory в журнале службы Не удалось выделить память: предел службы, память машины, настройка overcommit, исчерпанные области отображения.
Disk quota exceeded для службы Место на разделе есть, а запись отклоняется: исчерпана дисковая квота пользователя или группы.
Elasticsearch: max virtual memory areas vm.max_map_count is too low Elasticsearch отказывается стартовать из-за заниженного vm.max_map_count. Как поднять значение и закрепить его.

Источники

journald.conf(5)
RateLimitIntervalSec= и RateLimitBurst=. официальная документация, systemd 255
сверено 15 сентября 2026
systemd.exec(5)
LogRateLimitIntervalSec= и LogRateLimitBurst= для отдельной службы. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено службой, пишущей десятки тысяч строк в минуту. собственная проверка, systemd 255
сверено 15 сентября 2026