мешает работе ресурсы память

Служба замедляется при упоре в MemoryHigh

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

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

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

Потребление превысило мягкий предел

Предел задан осознанно как «дальше не разгоняйся». При его превышении ядро давит на службу.
Машина в целом испытывает нехватку памяти

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

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

Диагностика

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

Показатель давления памяти по всей машине.

cat /proc/pressure/memory

Все счётчики и пределы памяти службы.

systemctl show myapp.service | grep -E "^Memory"

Кто потребляет память сейчас.

systemd-cgtop -1 --order=memory | head -12

Решение

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

1. Потребление превысило мягкий предел

Почему происходит: Предел задан осознанно как «дальше не разгоняйся». При его превышении ядро давит на службу.

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

Посмотрите предел, потребление и показатель давления.

systemctl show myapp.service -p MemoryHigh -p MemoryCurrent -p MemoryMax
cat /sys/fs/cgroup/system.slice/myapp.service/memory.pressure 2>/dev/null

Как исправить: Либо поднимите предел, либо уменьшите потребление службы. Показатель давления — надёжный признак, что упор действительно есть.

2. Машина в целом испытывает нехватку памяти

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

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

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

cat /proc/pressure/memory
free -h

Как исправить: Найдите главного потребителя и ограничьте его. Общая нехватка не лечится настройкой одной службы.

3. Активная подкачка

Почему происходит: Служба, страницы которой ушли в подкачку, работает в разы медленнее. Это видно по счётчикам обмена.

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

Посмотрите обмен с подкачкой.

vmstat 2 3
systemctl show myapp.service -p MemorySwapCurrent -p MemorySwapMax

Как исправить: Ограничьте подкачку для службы через MemorySwapMax=0, если для неё важнее предсказуемая скорость, чем выживание при нехватке памяти.

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

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

$ systemctl show myapp.service -p MemoryHigh -p MemoryCurrent
MemoryHigh=1073741824
MemoryCurrent=1181116006

$ cat /sys/fs/cgroup/system.slice/myapp.service/memory.pressure
some avg10=42.18 avg60=38.02 avg300=21.55 total=91238412

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

Failed with result 'oom-kill' Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
Cannot allocate memory в журнале службы Не удалось выделить память: предел службы, память машины, настройка overcommit, исчерпанные области отображения.
Служба работает медленно: упор в CPUQuota Квота процессора ограничивает службу: признаки, как измерить и когда квота вредна.
status=204/MEMORY в systemd Код 204/MEMORY: systemd не смог выделить память при подготовке запуска службы. Что проверять на машине и в unit-файле.
systemd-oomd остановил службу из-за нехватки памяти Служба остановлена не ядром, а системной службой наблюдения за памятью: критерий другой, и настраивается он иначе.
Disk quota exceeded для службы Место на разделе есть, а запись отклоняется: исчерпана дисковая квота пользователя или группы.
Elasticsearch: max virtual memory areas vm.max_map_count is too low Elasticsearch отказывается стартовать из-за заниженного vm.max_map_count. Как поднять значение и закрепить его.
Elasticsearch: служба падает из-за размера кучи JVM Размер кучи больше доступной памяти или больше предела службы: падение при старте или под нагрузкой.

Источники

systemd.resource-control(5)
MemoryHigh=, MemoryMax=, MemorySwapMax= и показатели давления. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Проверено на службе с MemoryHigh ниже фактического потребления. собственная проверка, systemd 255
сверено 15 сентября 2026