SystemdDoctor
служба не работает память ресурсы

systemd-oomd остановил службу из-за нехватки памяти

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

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

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

  1. Давление на память в срезе превысило порог

    Решение принимается по давлению, а не по объёму. Срез с активным обменом страницами останавливается даже при умеренном потреблении.

  2. Служба помечена как предпочтительная для остановки

    Пометка в описании службы делает её первой целью. Пометка могла быть унаследована из шаблона.

  3. Остановку службой наблюдения путают с остановкой ядром

    Это разные механизмы с разными причинами и настройками. Разбор по неверной ветке уходит в сторону.

Диагностика

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

Решения службы наблюдения за памятью.

journalctl -u systemd-oomd -b --no-pager

Пометки и пределы памяти службы.

systemctl show myapp.service -p ManagedOOMPreference -p MemoryMax -p MemoryHigh

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

systemd-cgtop -1 -n1 -m | head -10

Решение

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

1. Давление на память в срезе превысило порог
Почему происходит
Решение принимается по давлению, а не по объёму. Срез с активным обменом страницами останавливается даже при умеренном потреблении.
Как проверить
Посмотрите сообщения службы наблюдения и давление на память. 
journalctl -u systemd-oomd -b --no-pager | tail -10
cat /sys/fs/cgroup/system.slice/myapp.service/memory.pressure 2>/dev/null
Как исправить
Ограничьте потребление памяти службы или снизьте её нагрузку. Настройка порогов задаётся в описании срезов, а не в самой службе.
2. Служба помечена как предпочтительная для остановки
Почему происходит
Пометка в описании службы делает её первой целью. Пометка могла быть унаследована из шаблона.
Как проверить
Посмотрите пометки службы и её среза. 
systemctl show myapp.service -p ManagedOOMPreference -p ManagedOOMSwap -p ManagedOOMMemoryPressure
Как исправить
Уберите пометку предпочтения или наоборот пометьте службу как избегаемую, если она важнее остальных. 
[Service]
ManagedOOMPreference=avoid
3. Остановку службой наблюдения путают с остановкой ядром
Почему происходит
Это разные механизмы с разными причинами и настройками. Разбор по неверной ветке уходит в сторону.
Как проверить
Сравните сообщения обеих подсистем. 
journalctl -b --no-pager | grep -iE "systemd-oomd|Out of memory: Killed process" | tail -10
Как исправить
Определите источник по сообщению: служба наблюдения называет срез, ядро называет процесс и его потребление.

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

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

systemd-oomd[720]: Considered 4 cgroups for killing, top candidate was: /system.slice/myapp.service
systemd-oomd[720]: Killed /system.slice/myapp.service due to memory pressure for /system.slice being 62.01% > 60.00% for > 20s with reclaim activity
systemd[1]: myapp.service: systemd-oomd killed some process(es) in this unit.

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

Где встречается чаще всего

Источники

  • systemd-oomd.service(8)
    Критерии остановки срезов по давлению на память.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • systemd.resource-control(5)
    ManagedOOMPreference= и связанные параметры.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Проверено на systemd 255: сообщения службы наблюдения отличаются от сообщений ядра.     собственная проверка, systemd 255
    сверено 15 сентября 2026