Сценарий: OOMKilled
Вопрос
Под периодически перезапускается с OOMKilled. Как найдёшь причину и что предложишь?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Подтвердить: `describe` (Reason OOMKilled, 137), не путать с Evicted
Посмотреть график памяти контейнера до падения: резкий пик или постоянный рост (утечка)
Сравнить лимит с реальным пиком; проверить лимит кучи рантайма (JVM, Node, Go) относительно лимита контейнера
Учесть всю память процесса: нативные буферы, потоки, page cache в cgroup
Утечка: профилирование кучи, heap dump, сравнение снимков
Решение: исправить утечку или ограничить кучу, выставить лимит по данным, requests = limits для памяти
Что могут спросить следом
- Почему лимит кучи JVM должен быть меньше лимита контейнера?
- Как отличить утечку от нормального роста?
Разбор
Сначала убеждаюсь, что это именно OOMKilled контейнера: в describe Reason OOMKilled и код 137. Если под Evicted, это нехватка памяти на узле, и разбор другой. Дальше смотрю график памяти контейнера в мониторинге за время до падения. Резкий пик говорит о тяжёлом запросе, загрузке большого файла в память или всплеске нагрузки. Плавный рост до лимита при постоянной нагрузке похож на утечку. Сравниваю лимит с реальным пиком и проверяю настройки рантайма: если у JVM куча равна лимиту контейнера, то метаспейс, стеки потоков и нативные буферы гарантированно выведут за лимит; кучу ставят 60-75% от лимита. Для Node --max-old-space-size, для Go GOMEMLIMIT. При утечке снимаю heap dump или профиль кучи в двух точках и сравниваю. Решения: исправить утечку, ограничить кучу и кеши, выставить лимит по данным с запасом, память делать requests равной limits. Поднимать лимит без понимания причины значит только отложить следующий OOM.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.