Как убийца OOM решает, какой процесс убить первым?

Этот ответ объясняет действия, предпринимаемые ядром при возникновении ситуации OOM, в зависимости от значения sysctl vm.overcommit_memory.

Когда overcommit_memoryустановлено значение 0 или 1, overcommitоно включено, и программам разрешается выделять больше памяти, чем реально доступно.

Что происходит, когда у нас заканчивается память в этой ситуации? Как убийца OOM решает, какой процесс убить первым?

Если память полностью израсходована процессами, в той степени, которая может угрожать стабильности системы, тогда появляется убийца OOM.

ПРИМЕЧАНИЕ. Задачей OOM Killer является продолжение процессов уничтожения до тех пор, пока не освободится достаточно памяти для бесперебойного функционирования остальной части процесса, который пытается запустить ядро.

OOM Killer должен выбрать лучший процесс (ы) для уничтожения. Под «лучшим» здесь понимается тот процесс, который высвободит максимум памяти при убийстве, а также наименее важный для системы.

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

Чтобы облегчить это, ядро ​​поддерживает oom_scoreдля каждого из процессов. Вы можете увидеть oom_scoreкаждый из процессов в /procфайловой системе в pidкаталоге.

$ cat /proc/10292/oom_score

Чем выше значение oom_scoreлюбого процесса, тем выше вероятность того, что OOM Killer будет убит в ситуации нехватки памяти.

Как OOM_Scoreрассчитывается?

В наборе патчей Дэвида старая эвристика badness () почти полностью исчезла. Вместо этого вычисление превращается в простой вопрос о том, какой процент доступной памяти используется процессом. Если системе в целом не хватает памяти, то «доступная память» - это сумма всей оперативной памяти и пространства подкачки, доступных системе.

Если вместо этого ситуация OOM вызвана исчерпанием памяти, разрешенной для данной группы процессоров / управления, то «доступная память» - это общий объем, выделенный этой группе управления. Аналогичный расчет выполняется, если превышены ограничения, налагаемые политикой памяти. В каждом случае использование памяти процессом считается суммой его резидентного набора (количества страниц ОЗУ, которое он использует) и использования его подкачки.

В результате этого вычисления получается число, умноженное на десять раз; процесс, использующий каждый байт доступной ему памяти, будет иметь оценку 1000, в то время как процесс, вообще не использующий память, получит нулевую оценку. Существует очень мало эвристических настроек для этой оценки, но код все же вычитает небольшое количество (30) из оценки процессов, принадлежащих корням, на том основании, что они немного более ценны, чем процессы, принадлежащие пользователям.

Еще одна хитрость, которая применяется, заключается в добавлении значения, хранящегося в переменной oom_score_adj каждого процесса, которое можно настроить с помощью / proc. Эта ручка позволяет регулировать привлекательность каждого процесса для убийцы OOM в пространстве пользователя; установка его в -1000 полностью отключит OOM-убийства, в то время как установка в +1000 эквивалентна рисованию большой цели в связанном процессе.

Рекомендации

http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326