cgroups и OOM-killer: кого убьют, почему в логе пусто и что на самом деле значит 137

Что здесь на самом деле спрашивают

Лестница обычно такая, и первые две ступени решают больше, чем кажется:

1. «Что такое cgroups?» — разминка: группировка, учёт, лимит.
2. «Что произойдёт, если процесс упрётся в лимит памяти?» — здесь отсеиваются те, кто ждёт MemoryError.
3. «Почему в логе приложения ничего нет?» — проверяют, связали ли вы это с SIGKILL из прошлого урока.
4. «Кого убьют, если в контейнере несколько процессов?» — знаете ли вы про оценку вредности и её основу.
5. «Как отличить OOM от остановки оркестратором, если код один и тот же?» — вопрос про улики, а не про догадки.
6. «Как выбирать лимит?» — понимаете ли вы, что failcnt и пик потребления говорят разные вещи.

Числа ниже получены прогоном bench/cgroups/oom.py и bench/cgroups/practice.py на cgroup v1. Во второй версии те же величины называются иначе (memory.max, memory.events, memory.peak) — механизм тот же, имена другие.

База: у контейнера есть бюджет памяти, и считает его не приложение

Прежде чем разбирать, кого и за что убивают, стоит назвать обычными словами три вещи.

Контрольная группа (cgroup) — это механизм ядра Linux, который считает ресурсы группы процессов и ограничивает их. Не одного процесса, а именно группы: ядро ведёт для неё счётчики — сколько памяти сейчас занято, сколько раз группа упиралась в потолок — и хранит число, которым это потребление ограничено.

Контейнер — это и есть такая группа. Когда в его настройках пишут «памяти 512 мегабайт», это число попадает в файл его группы, и дальше исполняет его ядро — не приложение, не среда исполнения и не библиотека.

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

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

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

Механизм 1: лимит принадлежит группе, а не процессу

Теперь то же самое словами документации. Контрольная группа — это набор процессов плюс учёт того, что они потребляют, и лимиты на потребление. Про память cgroups(7) говорит коротко:

Ключевое слово — cgroups, множественное число: и учёт, и лимит относятся к группе. Отсюда сразу два следствия, о которых спрашивают отдельно.

Первое: если в контейнере несколько процессов, они тратят общий лимит. Вспомогательный процесс, который «занимает всего сто мегабайт», отнимает эти сто мегабайт у основного.

Второе: убийство — это событие группы, а не процесса. Ядро обнаруживает, что группе некуда расти, и выбирает, кого из её членов убить. Тот, кого выбрали, мог не сделать ничего плохого.

Устроено это так: у группы есть файл с лимитом, файл с пиком потребления и счётчик попаданий в лимит (failcnt). Скрипт создаёт группу, ставит лимит в 64 МиБ и запускает в ней программу, которая честно просит 1600 МиБ, касаясь каждой страницы:

1. THE KILL: the limit is 64 MiB, the program asks for 1600
-----------------------------------------------------------
  limit (memory.limit_in_bytes)            64 MiB
  exit code from waitpid                   -9
  as the shell reports it                  137
  stdout of the program                    ''
  stderr of the program                    ''
  peak usage before the kill               64.0 MiB
  times the limit was hit (failcnt)        36

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

Механизм 2: потребление упирается в лимит, а не перерастает его

Самая частая неверная картинка: процесс «раздулся сверх лимита и лопнул». Посмотрите на пик: 64,0 МиБ при лимите 64 МиБ. В этом прогоне потребление дошло до лимита и не превысило его.

Границу этого наблюдения стоит назвать сразу, потому что дальше на него опирается практика. «Пик равен лимиту» — то, что мы измерили, а не обещание ядра: memory.max описан в документации cgroup v2 как предел, у которого потребление при некоторых обстоятельствах может временно оказаться выше. Поэтому правило пишется не от точности числа, а от причины: смерть наступает не после того, как процесс перерос лимит, а потому, что внутри группы стало нечего освобождать.

Программа в прогоне не просто просит память — она касается каждой страницы, и до счётчиков группы доходит именно занятое, а не запрошенное: просили 1600 МиБ, пик группы — 64,0 МиБ. Когда очередная страница не помещается в лимит, ядро её просто не выдаёт. Дальше есть два пути. Обычный — освободить что-нибудь в этой же группе и всё-таки выдать память. Крайний — если освобождать нечего, убить.

Первый путь и считает failcnt — та самая строка из блока выше:

  times the limit was hit (failcnt)        36

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

А теперь две пустые строки в том же блоке:

  stdout of the program                    ''
  stderr of the program                    ''

Ни MemoryError, ни трассировки, ни последнего сообщения в лог. Причина известна из прошлого урока и записана в signal(7): SIGKILL нельзя перехватить, заблокировать или проигнорировать. Программу не просили остановиться — её убрали.

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

Механизм 3: жертву выбирают по занятой памяти

Теперь вопрос, ради которого лестница и строилась: если в группе несколько процессов, кого убьют? Ответ записан в proc(5), и он не про очерёдность:

И отдельно — что считать «разрешённой памятью» в случае контейнера:

То есть оценка — это доля лимита группы, которую процесс занимает. Проверяем: в группе с лимитом 160 МиБ работают двое. Маленький занял 40 МиБ и держит их; большой просит 600.

3. WHO GETS KILLED: the biggest, not the last one
-------------------------------------------------
  small process (40 MiB, holding it)       alive
  big process (asked for 600 MiB)          killed
  victim                                   big

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

Подкрутить выбор можно вручную — oom_score_adj прибавляется к оценке, и диапазон известен:

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

Механизм 4: улика, по которой OOM отличают от остановки

Код 137 одинаков у процесса, убитого OOM-killer, и у процесса, которого добил чужой SIGKILL, — например, тот, что приходит в конце льготного срока при остановке контейнера из прошлого урока. В обоих случаях это 128 + 9. Различает их не код, а запись ядра — второй блок прогона:

2. THE KERNEL SAYS IT, THE APPLICATION DOES NOT
-----------------------------------------------
  constraint reported by the kernel        CONSTRAINT_MEMCG
  cgroup that ran out                      /de_oom_kill
  victim named by the kernel               python3

Поле constraint и говорит, где кончилась память. В прогоне ядро назвало группу: CONSTRAINT_MEMCG — значит, дело в её лимите. Если бы в строке была названа не группа, лечилось бы это совсем другим: не лимитом контейнера, а общим объёмом памяти машины.

Отсюда способ разобраться, которым стоит отвечать: у OOM есть свидетель, и это ядро. Три вопроса подряд — есть ли строка oom-kill:constraint= рядом по времени; какая группа в ней названа; и совпадает ли время с событием оркестратора. Если dmesg вы прочитали, а строки в нём нет, то и оснований называть это OOM нет: искать надо среди тех, кто имеет право посылать сигналы.

Глубже: тот же код, другой лимит — другой исход

Четвёртый блок прогона — тот же код, та же машина и тот же запрос на 1600 МиБ, но лимит 2048 МиБ:

4. THE SAME PROGRAM AND THE SAME REQUEST, A LIMIT THAT FITS
-----------------------------------------------------------
  limit                                    2048 MiB
  exit code                                0
  stdout of the program                    allocated 1600 MiB
  times the limit was hit (failcnt)        0

Ноль в failcnt и ноль в коде выхода. Ничего в программе не поменялось — поменялось разрешение.

Пятый блок отвечает на вопрос, который отсюда и возникает: любая ли память одинаково опасна? Через группу с лимитом 64 МиБ прочитан файл в 256 МиБ — вчетверо больше лимита:

5. PAGE CACHE COUNTS TOO, BUT IT CAN BE GIVEN BACK
--------------------------------------------------
  limit                                    64 MiB
  page cache dropped before the read       yes
  file read through the group              256 MiB
  exit code                                0
  stdout of the program                    read 256 MiB
  peak usage                               63.2 MiB
  times the limit was hit (failcnt)        95

Девяносто пять попаданий в лимит, пик у самого потолка — и код выхода ноль. Страницы файлового кеша считаются группе, но их можно вернуть, и ядро их вернуло. Не возвращается анонимная память — та, из-за которой погиб процесс в первом блоке.

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

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

• пик потребления говорит, сколько группе нужно в худшем виденном случае;
• failcnt говорит, сколько раз она упиралась в текущий лимит.

Пик близко к лимиту и failcnt растёт — запас исчерпан, следующий всплеск кончится убийством. failcnt ноль и пик втрое меньше лимита — лимит завышен, и за этот запас кто-то платит: на плотно упакованной машине он отнят у соседей.

Как отвечать на собеседовании

Короткий ответ: лимит памяти ставится группе процессов, и при упирании в него ядро сначала пытается освободить память внутри группы, а если не выходит — убивает одного из её процессов сигналом SIGKILL. Поэтому в логе приложения пусто, а снаружи видно 137 — это 128 + 9. Потребление при этом за лимит не улетает: в измеренном прогоне пик группы дошёл ровно до лимита и остановился.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Хороший ответ отличают три детали. Первая — вы говорите, что упирание в лимит не равно смерти: счётчик failcnt растёт и у совершенно здоровой группы, это признак жизни на границе. Вторая — вы называете основу выбора жертвы: доля занятой памяти от лимита, а не очерёдность запросов. Третья — вы знаете улику, которая отличает OOM от остановки оркестратором: строка ядра с constraint=CONSTRAINT_MEMCG и именем группы; кода выхода для этого недостаточно.

И одна вещь, на которой легко переусердствовать. Сказать «процесс не превышает лимит ни на байт» — значит выдать замер за гарантию. Пик у нас действительно дошёл до лимита и не превысил его, но memory.max описан в документации cgroup v2 как предел, у которого потребление при некоторых обстоятельствах может временно оказаться выше. Точная формулировка звучит так: убивают не за превышение, а за то, что освобождать внутри группы стало нечего — и проверяется это не арифметикой, а пиком и failcnt в файлах группы.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

group = make_group("de_practice_kill", 64)
done = subprocess.run(
  [sys.executable, "-c", EATER, group, "1600"], capture_output=True, text=True
)
print(128 - done.returncode)
print(done.stderr.strip() or "none")
print(victim_of(make_group("de_practice_victim", 160)))

137
none
big

137
MemoryError
big

1
MemoryError
small

137
none
small

Проверка знаний