Что такое oom killer
Ordnung muß sein. Ordnung über alles (18+)
Инструменты пользователя
Инструменты сайта
Боковая панель
Навигация
Линкшэринг
socialite Display:icon facebook twitter
ALARM!
Добавить новую страницу
Реклама
Содержание
Что такое OOM и oom-killer Out of memomy, killer, oom-killer
Теория
Практика
OOM, Out of memomy, killer, oom-killer
Перезагрузка при OOM
Мы можем настроить систему таким образом, чтобы при OOM у нас был kernel panic и система автоматически перезагружалась.
Скопирую часть из документации с сайта kernel.org
This enables or disables panic on out-of-memory feature.
If this is set to 0, the kernel will kill some rogue process, called oom_killer. Usually, oom_killer can kill rogue processes and system will survive.
If this is set to 1, the kernel panics when out-of-memory happens. However, if a process limits using nodes by mempolicy/cpusets, and those nodes become memory exhaustion status, one process may be killed by oom-killer. No panic occurs in this case. Because other nodes’ memory may be free. This means system total status may be not fatal yet.
If this is set to 2, the kernel panics compulsorily even on the above-mentioned. Even oom happens under memory cgroup, the whole system panics.
The default value is 0. 1 and 2 are for failover of clustering. Please select either according to your policy of failover. panic_on_oom=2+kdump gives you very strong tool to investigate why oom happens. You can get snapshot.
Устанавливаем параметры для ядра через sysctl
Или чтобы настройки остались после перезагрузки вносим их в файл sysctl
Выделенная память подов и вмешательство OOM Killer
И снова здравствуйте! Перевод следующей статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes», который запускается уже в этом месяце Начнем.
В последние дни некоторые из моих подов постоянно аварийно завершали работу, оставляя в системном журнале ОС запись о том, что OOM Killer уничтожил процесс контейнера. Я решил разобраться, почему это происходит.
Лимит памяти подов и параметры памяти cgroup
Проведем тест на дистрибутиве K3s. Создаем под с характерным лимитом памяти — 123 МиБ (123 Mi).
В другой консоли выясняем uid пода.
128974848 — это ровно 123 МиБ (123*1024*1024). Ситуация проясняется. Выходит, в Kubernetes лимит памяти задается через cgroup. Как только под разрастется больше отведенного лимита памяти, cgroup инициирует уничтожение процесса контейнера.
Стресс-тест
Давайте установим утилиты для стресс-тестирования пода через открытый сеанс командной консоли.
Сначала запустим утилиту стресс-тестирования, выделив ей в памяти 100 МБ. Процесс запустился успешно.
Теперь проведем второй стресс-тест.
Запуск привел к мгновенному уничтожению процесса первого стресс-теста (PID 271) по сигналу 9.
Тем временем в системном журнале появились такие записи:
Процесс с PID 32308 на хосте уничтожен в связи с нехваткой памяти (OOM). Но самое интересное скрывается в конце журнальных записей:
Выясняем объем памяти, доступной узлу:
Итак, все процессы в контейнере обладают одинаковым значением oom_score_adj. Компонент OOM Killer рассчитывает значение OOM, исходя из использования памяти, и корректирует результат с учетом оценки oom_score_adj. И, в конечном счете, он уничтожает процесс первого стресс-теста, который отъел большую часть памяти, 100 МБ, что соответствует оценке oom_score = 1718.
Заключение
Kubernetes контролирует лимит памяти подов через параметры cgroup и компонент OOM Killer. Необходимо внимательно согласовывать условия OOM операционной системы и OOM подов.
Как вам материал? Всех, кто желает подробнее узнать о курсе, приглашаем 17 июня на бесплатный вебинар, где изучим возможности Kubernetes для организации практики непрерывной поставки (CI/CD) и подходы как для небольшой команды с несколькими приложениями, так и для большой организации с большим количеством систем.
Настраиваем Out-Of-Memory Killer в Linux для PostgreSQL
Когда в Linux сервер базы данных непредвиденно завершает работу, нужно найти причину. Причин может быть несколько. Например, SIGSEGV — сбой из-за бага в бэкенд-сервере. Но это редкость. Чаще всего просто заканчивается пространство на диске или память. Если закончилось пространство на диске, выход один — освободить место и перезапустить базу данных.
Out-Of-Memory Killer
Когда у сервера или процесса заканчивается память, Linux предлагает 2 пути решения: обрушить всю систему или завершить процесс (приложение), который съедает память. Лучше, конечно, завершить процесс и спасти ОС от аварийного завершения. В двух словах, Out-Of-Memory Killer — это процесс, который завершает приложение, чтобы спасти ядро от сбоя. Он жертвует приложением, чтобы сохранить работу ОС. Давайте сначала обсудим, как работает OOM и как его контролировать, а потом посмотрим, как OOM Killer решает, какое приложение завершить.
Одна из главных задач Linux — выделять память процессам, когда они ее просят. Обычно процесс или приложение запрашивают у ОС память, а сами используют ее не полностью. Если ОС будет выдавать память всем, кто ее просит, но не планирует использовать, очень скоро память закончится, и система откажет. Чтобы этого избежать, ОС резервирует память за процессом, но фактически не выдает ее. Память выделяется, только когда процесс действительно собирается ее использовать. Случается, что у ОС нет свободной памяти, но она закрепляет память за процессом, и когда процессу она нужна, ОС выделяет ее, если может. Минус в том, что иногда ОС резервирует память, но в нужный момент свободной памяти нет, и происходит сбой системы. OOM играет важную роль в этом сценарии и завершает процессы, чтобы уберечь ядро от паники. Когда принудительно завершается процесс PostgreSQL, в логе появляется сообщение:
Выбор процесса
Выполнив все эти проверки, OOM изучает оценку ( oom_score ). OOM назначает oom_score каждому процессу, а потом умножает это значение на объем памяти. У процессов с большими значениями больше шансов стать жертвами OOM Killer. Процессы, связанные с привилегированным пользователем, имеют более низкую оценку и меньше шансов на принудительное завершение.
Идентификатор процесса Postgres — 3813, поэтому в другой оболочке можно получить оценку, используя этот параметр ядра oom_score :
Принудительное завершение процесса
Как контролировать OOM-Killer
Чтобы отключить OOM-Killer, укажите значение 0 в этой же команде:
Результат этой команды сохранится не навсегда, а только до первой перезагрузки. Если нужно больше постоянства, добавьте эту строку в файл /etc/sysctl.conf :
Если установить значение 0, то когда закончится память, kernel panic не будет.
Если установить значение 1, то когда закончится память, случится kernel panic.
Для нее можно указывать следующие значения:
OOMkiller в Docker сложнее, чем вы думаете
Снова здравствуйте. В преддверии старта курса «Разработчик Java» подготовили перевод еще одного небольшого материала.
Недавно у одного из пользователей Plumbr APM возникла странная проблема с аварийной остановкой docker-контейнера с кодом 137. Конфигурация была простейшая с несколькими вложенными контейнерами и виртуальными машинами, похожая на матрешку:
Смотрим syslog и видим, что, действительно, был вызван oomkiller:
Как видно, java-процесс достиг лимита в 3145728 кБ (это около 3ГБ), что и вызвало остановку контейнера. Это довольно странно, так как сам docker был запущен с ограничением в 4 ГБ (в файле docker-compose ).
Пока мы не понимаем, что происходит. Docker должен разрешить использовать 4 ГБ. Так почему же OOMkiller сработал на 3 ГБ? Дальнейший поиск информации привел нас к тому, что есть еще одно ограничение памяти в ОС, которая была развернута на железе.
Скажите спасибо cgroups (control groups, контрольные группы). cgroups — это механизм ядра Linux для ограничения, контроля и учета использования ресурсов группами процессов. По сравнению с другими решениями (команда nice или /etc/security/limits.conf ), cgroups предоставляют большую гибкость, так как они могут работать с (под)наборами процессов.
В нашей ситуации cgroups ограничивали использование памяти в 3 ГБ (через memory.limit_in_bytes ). У нас определённый прогресс!
Исследование памяти и событий GC с помощью Plumbr показало, что большую часть времени JVM использовало около 700 МБ. Исключение было только непосредственно перед остановкой, когда происходил всплеск выделения памяти. За ним следовала длительная пауза GC. Итак, кажется, происходило следующее:
Выводы
Даже в такой простой ситуации, было три ограничения памяти:
Еще один вывод для разработчиков docker. Кажется, нет смысла разрешать запускать такие «матрешки», в которых ограничение памяти вложенного контейнера выше, чем ограничение cgroups. Простая проверка этого при запуске контейнера с отображением соответствующего предупреждения может сэкономить сотни часов отладки для ваших пользователей.
Как отключить Out of memory или oom-killer в CentOS / RHEL
Что такое OOM Killer?
Убийца OOM, включенный по умолчанию, является механизмом самозащиты, использующим ядро Linux при сильном использовании памяти.
Если ядро не может найти память для выделения, когда это необходимо, она помещает страницы пользовательских данных в очередь подкачки.
Если виртуальная память (VM) не может выделять память и не может поменять ее в используемой памяти, киллер может начать убивать текущие процессы из памяти в пользовательском пространстве. он пожертвует одним или несколькими процессами, чтобы освободить память для системы, когда все остальное не удастся.
Если у вас есть строка, как показано ниже в / var / log / messages:
Отключение OOM-KILLER в CentOS / RHEL
В Red Hat Enterprise Linux 5 и 6 нет возможности полностью отключить OOM-KILLER. См. Следующий раздел для настройки работы OOM-KILLER в RHEL 5 и RHEL 6.
Можно определить, какие процессы будут убиты путем корректировки оценки oom_killer.
В / proc / PID / есть два инструмента с метками oom_adj и oom_score.
Это значение используется для вычисления «плохого» процесса с использованием алгоритма, который также учитывает, как долго процесс был запущен, среди других факторов.
Чтобы увидеть текущий счет oom_killer, просмотрите oom_score для процесса.
oom_killer сначала уничтожит процессы с наивысшими баллами.
В этом примере настраивается oom_score процесса с помощью PID 12465, чтобы уменьшить вероятность того, что oom_killer убьет его.
В приведенном ниже примере oom_score возвращает значение 0, указывая, что этот процесс не будет убит.
Установка «overcommit_memory» на 2, позволяет вам быть точным в отношении избыточной памяти.
Оно указывает, что ядро никогда не будет выполнять адресное пространство, большее, чем пространство подкачки, и фракцию «overcommit_ratio» физической памяти.
Когда использование памяти попадает в этот номер, больше не должно быть никаких ассигнований.
Committed_AS в / proc / meminfo показывает текущий объем памяти в системе.
Заключение
Out of Memory (OOM) относится к вычислительному состоянию, в котором выделена вся доступная память, включая пространство подкачки.
Обычно это приведет к panic error и остановке системы.
Хотя OOM нельзя полностью отключить в CentOS / RHEL 5,6; он может быть настроен на то, чтобы определить, какие процессы будут убиты, отрегулировав счет oom_killer.