Почему OOM-Killer не может просто убить процесс, который требует слишком много?

Это объясняется здесь , что ОАЯ-убийца может быть сконфигурирована с помощью overcommit_memoryи что:

2 = без перегрузки. Распределение не удастся, если просить слишком много.
0, 1 = перегрузка (эвристически или всегда). Убейте какой-нибудь процесс (ы) на основе некоторой эвристики, когда слишком большой доступ к памяти фактически получен.

Теперь я могу полностью понять это неправильно, но почему нет возможности (или почему это не значение по умолчанию), чтобы убить тот самый процесс, который фактически пытается получить доступ к слишком большому количеству выделенной памяти?

linux out-of-memory

— Мартин Ба
источник

Что если критический системный процесс запрашивает слишком много памяти?

— Лоуренс

Во-первых, он может сделать это. Но самая большая проблема в этом вопросе состоит в том, что, по всей вероятности, если процесс запрашивает память, то он выполняется заново - или, другими словами, это новый процесс, вовлеченный в очень актуальную обработку. Вы бы предпочли, чтобы OOM позволил вашему не открытому в течение 3 дней im-клиенту тратить системную память впустую, или вы бы предпочли, чтобы YouTube действительно загружался в этом году? linuxatemyram.com

— mikeserv

Это то, что по no overcommitсути делает опция. Если процесс запрашивает слишком много памяти, он терпит неудачу. Если он проверяет на ошибку, он обычно убивает себя; если этого не произойдет, он, вероятно, получит ошибку сегментации, когда попытается разыменовать malloc()возвращаемый нулевой указатель , и произойдет сбой.

— Бармар

Обратите внимание, что 2 на самом деле является no overcommitрежимом, согласно цитируемым источникам (таким как kernel.org/doc/Documentation/vm/overcommit-accounting ). Я думаю, что я отредактирую ваш вопрос соответственно.

— hans_meine

Рассмотрим этот сценарий:

У вас есть 4 ГБ свободной памяти.
Неисправный процесс выделяет 3,999 ГБ.
Вы открываете диспетчер задач, чтобы убить сбежавший процесс. Диспетчер задач выделяет 0,002 ГБ.

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

Или:

У вас есть 4 ГБ свободной памяти.
Неисправный процесс выделяет 3,999 ГБ.
Вы открываете диспетчер задач, чтобы убить сбежавший процесс. X-сервер выделяет 0,002 ГБ для обработки окна диспетчера задач.

Теперь ваш X-сервер убит. Это не вызвало проблемы; это было просто "в неправильном месте в неподходящее время". Это был первый процесс, который выделил больше памяти, когда ничего не осталось, но это был не тот процесс, который использовал всю память для начала.

— user253751
источник

Расширение вашего примера означает, что если бы процесс потреблял 99,999% вашей памяти, вы бы никогда не смогли его уничтожить, поскольку все, что могло бы его уничтожить, потребовало бы памяти и, следовательно, самоубийство, прежде чем ошибочный процесс мог быть уничтожен!

— сани

Имейте в виду, это философия Linux, а не необходимый факт. Windows 3.0 решила эту проблему, зарезервировав достаточно памяти для обработки OOM, включая необходимые диалоги.

— MSalters

@MSalters: Это не относится к примеру; Пример был о процессе, который зарезервировал почти всю память, т.е. недостаточно, чтобы убить себя. Очевидно, должно быть достаточно памяти, зарезервированной для обработки OOM в любой ОС. Но процесс, который вызывает обработку OOM, будет следующим процессом, который произойдет с резервированием памяти, а не с неправильным поведением. Если, конечно, вы не имели в виду, что в Windows 3.0 всегда было достаточно памяти, зарезервированной для запуска диспетчера задач, или что обработчик OOM всегда предлагал пользователю завершить процесс. (Который! =

— Убивает

@AleksiTorhamo: я действительно имел в виду последнее. В Windows 3.0 не было полнофункционального диспетчера задач, в нем были знаменитые синие экраны, память которых была предварительно выделена.

— MSalters