Чому OOM-Killer не може просто вбити процес, який вимагає занадто багато?

Це пояснюється тут , що ОАЯ-вбивця може бути налаштована з допомогою overcommit_memoryі що:

2 = відсутність перевиконання. Виділення не вдається, якщо запитати занадто багато.
0, 1 = перевиконання (евристично або завжди). Убийте якийсь процес на основі евристики, коли доступ до занадто багато пам'яті.

Тепер я можу повністю зрозуміти це, але чому немає варіанту (або чому це не за замовчуванням), щоб вбити той самий процес, який насправді намагається отримати занадто багато виділеної йому пам'яті?

linux out-of-memory

— Мартін Ба
джерело

Що робити, якщо критичний системний процес вимагає занадто багато пам'яті?

— Лоуренс

В першу чергу - це може зробити це. Але найбільша проблема з цим питанням полягає в тому, що, швидше за все, якщо процес вимагає пам'яті, то він нещодавно виконується - або, іншими словами, це новий процес, який бере участь у дуже поточній обробці. Ви хочете, швидше за все, OOM дозволив вашому клієнту, який не був відкритий протягом 3-х днів, продовжувати витрачати системну пам'ять, або ви хочете, щоб YouTube фактично завантажив деякий час у цьому році? linuxatemyram.com

— mikeserv

Це те, що по no overcommitсуті робить варіант. Якщо процес вимагає занадто багато пам'яті, він виходить з ладу. Якщо він перевірить на помилку, він зазвичай вбиває себе; якщо цього не відбудеться, він, ймовірно, отримає помилку сегментації, коли спробує знешкодити нульовий покажчик, який malloc()повертається, і він вийде з ладу.

— Бармар

Зауважте, що 2 - це власне no overcommitрежим, згідно з цитованими джерелами (наприклад, kernel.org/doc/Documentation/vm/overcommit-accounting ). Думаю, я відповідно відредагую ваше запитання.

— hans_meine

Розглянемо цей сценарій:

У вас немає 4 Гб пам'яті.
Несправний процес виділяє 3,99 Гб.
Ви відкриваєте диспетчер завдань, щоб убити процес, що втікає. Диспетчер завдань виділяє 0,002 Гб.

Якщо процес вбитого був останнім процесом, який вимагав пам'яті, ваш менеджер із завдань загинув.

Або:

У вас немає 4 Гб пам'яті.
Несправний процес виділяє 3,99 Гб.
Ви відкриваєте диспетчер завдань, щоб убити процес, що втікає. X-сервер виділяє 0,002 Гб для обробки вікна менеджера завдань.

Тепер ваш X-сервер вбивається. Це не спричинило проблеми; це було просто «в неправильному місці в неправильний час». Це сталося першим процесом, який виділив більше пам’яті, коли не залишилося нічого, але це не той процес, який використовував усю пам’ять для початку.

— користувач253751
джерело

Щоб розширити свій приклад, це означає, що якби процес займав 99,999% вашої пам’яті, ви ніколи не зможете його вбити, оскільки все, що може вбити, вимагало б пам’яті, а значить, і вбийте себе до того, як процес заблудження може бути вбитий!

— Санки

Зауважте, це філософія Linux, а не необхідний факт. Windows 3.0 вирішив це, маючи достатню кількість пам'яті, зарезервованої для обробки OOM, включаючи необхідні діалоги.

— MSalters

@MSalters: Однак це насправді не стосується прикладу; Приклад був про процес, який зарезервував майже всю пам'ять, тобто. недостатньо, щоб вбити себе МОМ. Очевидно, що для роботи з OOM в будь-якій ОС має бути достатньо пам'яті. Але процес, який викликає обробку OOM, буде наступним процесом, який трапляється резервувати пам'ять, а не погано поводитися. Якщо, звичайно, ви не мали на увазі, що в Windows 3.0 завжди було достатньо пам’яті, зарезервованої для запуску диспетчера завдань, або що обробник OOM завжди спонукав користувача до вбивства. (Що! = Вбивство ображаючого процесу)

— Алексі Торхамо

@AleksiTorhamo: Я дійсно мав на увазі останнє. У Windows 3.0 не було повноцінного менеджера завдань, у нього були знамениті сині екрани, пам'ять яких була попередньо виділена.

— MSalters