Автоматическая реакция на OOM через systemd и cgroups: перезапуск и контроль памяти

OOM (Out Of Memory) - это не просто “закончилась память”. В Linux это механизм, при котором ядро начинает принудительно завершать процессы, чтобы система не упала целиком.

Проблема в том, что без контроля первым под нож часто попадает не тот процесс, который должен.

▪️Как systemd влияет на OOM

systemd работает поверх cgroups и может задавать приоритеты “жертвенности” процессов:

systemd-cgtop

Показывает, какие группы потребляют память.

▪️Контроль памяти на уровне unit

Можно ограничить сервис:

[Service]
MemoryMax=500M

Теперь процесс физически не сможет превысить лимит.

Дополнительно:

MemoryHigh=400M



Это мягкий порог - systemd начинает давить на процесс раньше, чем наступит OOM.

▪️Влияние на OOM Killer
Можно управлять приоритетом уничтожения:

OOMScoreAdjust=-500

или наоборот:

OOMScoreAdjust=500



Чем выше значение - тем выше шанс, что процесс будет убит первым.

▪️Автоматический перезапуск после OOM
systemd может перезапускать сервис даже после убийства ядром:

[Service]
Restart=on-failure
RestartSec=2



Это работает и для OOM-kill, потому что процесс считается завершённым с ошибкой.

▪️Практический сценарий
Типичная ситуация:

• сервис разогнал память
• ядро убивает его через OOM
• systemd фиксирует падение
• запускает новый экземпляр
• cgroups не дают повторно выйти за лимит

▪️Где начинается реальный контроль

Ключевой момент - сочетание:

• MemoryMax (жёсткий лимит)
• MemoryHigh (раннее давление)
• OOMScoreAdjust (приоритет убийства)
• Restart=on-failure (самовосстановление)

▪️Почему это важно

Без cgroups OOM - это хаос: ядро выбирает жертву само.

С systemd это превращается в управляемую систему: процесс либо не доходит до OOM, либо корректно переживает его через перезапуск и ограничение ресурсов.

BashTex 📱 #scripts #linux