В этом материале
Контейнер может заметно замедлиться, оставаясь живым и не достигая OOM. В cgroup v2 memory.high запускает ограничение через reclaim и торможение выделений; memory.max задаёт другую, жёсткую границу. Поэтому отсутствие перезапуска ещё не исключает ограничения системной памяти.
Контейнер может заметно замедлиться, оставаясь живым и не достигая OOM. В cgroup v2 memory.high запускает ограничение через reclaim и торможение выделений; memory.max задаёт другую, жёсткую границу. Поэтому отсутствие перезапуска ещё не исключает ограничения системной памяти.
Найдите cgroup именно рабочего процесса
Сохраните PID процесса на хосте и его путь в /proc/PID/cgroup. Затем определите соответствующий каталог unified hierarchy. Путь внутри контейнера может отличаться от представления хоста: cgroup namespace скрывает часть иерархии. Для диагностики нужны значения действующего ограничения, а не только YAML, который когда-то использовался при запуске. Рядом запишите версию ядра, runtime и время наблюдения, чтобы последующая миграция процесса не смешала два разных состояния.
Сопоставьте четыре файла
Читайте memory.current, memory.high, memory.max и memory.events в одном интервале. Счётчики событий накопительные: одиночное большое число не доказывает, что проблема продолжается сейчас. Снимите значения до и после воспроизводимого замедления. У memory.events есть иерархическая семантика; memory.events.local помогает отделить локальные события от потомков. Также проверьте родительские группы: ограничение предка действует даже при свободном бюджете дочернего контейнера.
Разберите небольшой пример
В учебном случае worker имеет memory.max 12 GiB и memory.high 8 GiB. При обработке набора данных memory.current держится около 9 GiB, high увеличивается, oom_kill не меняется. Это совместимо с reclaim под мягкой границей, но не является измеренным результатом какой-либо площадки. Следующим подтверждением служат memory.pressure и задержка процесса в том же временном окне.
| Наблюдение | Что проверять дальше |
|---|---|
| Растёт high | Reclaim и давление внутри действующей иерархии |
| Растёт oom_kill | Завершённые процессы и предел memory.max |
| Счётчики стабильны | Другие причины задержки, включая CPU и сеть |
Измените одну границу
Если проблема подтверждена, сопоставьте рабочий объём данных с выделенным бюджетом. Можно сократить одновременно обрабатываемую порцию либо согласованно изменить memory.high, сохранив достаточный запас хоста. Повышение high до max убирает ранний сигнал давления и меняет поведение соседних задач. Учитывайте, что освобождённая память и файловый кеш могут меняться постепенно; мгновенный снимок после исправления плохо описывает устойчивое состояние. Не отключайте OOM protection вместо исследования причин.
Зафиксируйте критерий восстановления
Повторите тот же набор работы с прежними входами, сохранив длительность, прирост high, oom_kill и PSI. Успех означает, что исчезло подтверждённое ограничение при приемлемом давлении на хост, а не просто вырос разрешённый лимит. Оставьте запись с путём cgroup, прежними значениями и способом возврата. Она позволит объяснить повторный случай после обновления runtime и обнаружить, если новый контейнер оказался в другой родительской группе.
Для отдельного сравнения выполните одинаковую небольшую операцию после периода покоя и во время подтверждённого pressure. Сопоставляйте именно прирост событий: старый ненулевой high сохранится после исправления, поэтому обнуления накопленного счётчика ожидать не нужно.
Связанные разборы: memory optimized hosting; ram vs vram.