Чи можливо змусити вбивцю ООМ втручатися раніше?

Я намагаюся налаштувати свою систему розвитку на максимальну надійність. Я відключив своп, оскільки для використання графічного інтерфейсу він здебільшого робить машину невідповідною таким чином, що більше не використовується. Тим не менш, якщо агресивні програми з’їдають пам’ять, деякі механізми, здається, вдаряють у тому, щоб максимально використати її за рахунок швидкості. Не існує жодної операції заміни жорсткого диска, але система також не реагує. Тож я хочу дозволити вбивці OOM вбитись до того, як система докладе особливих зусиль щодо збільшення пам'яті. Чи можна налаштувати вбивцю OOM для дії, якщо, наприклад, менше 100 Мб вільної фізичної пам'яті?

Я також боровся з цим питанням. Я просто хочу, щоб моя система залишалася чуйною, незважаючи ні на що, і я вважаю за краще програвати процеси перед тим, як чекати кілька хвилин. Здається, немає можливості досягти цього за допомогою вбивці oom ядра.

Однак у користувальницькому просторі ми можемо робити все, що завгодно. Тож я написав Daemon Early OOM ( https://github.com/rfjakob/earlyoom ), який знищить найбільший процес (за RSS), коли наявна оперативна пам'ять опуститься нижче 10%.

Без раннього зусилля, було легко зафіксувати мою машину (8 ГБ оперативної пам’яті), запустивши http://www.unrealengine.com/html5/ кілька разів. Тепер винні вкладки браузера вбиваються, перш ніж речі вийдуть з-під руки.

Політика ядра за замовчуванням полягає в тому, щоб програми могли продовжувати виділяти віртуальну пам'ять до тих пір, поки не буде вільної фізичної пам'яті. Фізична пам'ять насправді не використовується, поки додатки не торкнуться виділеної ними віртуальної пам'яті, тому програма може виділити набагато більше пам’яті, ніж система, а потім почати торкатися її пізніше, в результаті чого у ядра не вистачає пам’яті і не викликається вихід вбивці пам'яті (OOM). Перед тим, як процес зависання буде вбито, це призвело до спорожнення кеш-диска, що змушує систему повільно реагувати на деякий час, поки кеш не поповниться.

Ви можете змінити політику за замовчуванням, щоб заборонити перезавантажувати пам'ять, записавши значення 2 до /proc/sys/vm/overcommit_memory. Значення за замовчуванням /proc/sys/vm/overcommit_ratio- 50, тому ядро ​​не дозволить програмам виділяти більше 50% ram + swap. Якщо у вас немає swap, ядро ​​не дозволить програмам виділяти більше 50% вашого оперативної пам’яті, залишаючи інші 50% вільними для кешу. Це може бути трохи надмірним, тому ви, можливо, захочете збільшити це значення, скажімо, на 85% або близько того, тому програми можуть виділити до 85% вашого барана, залишаючи 15% для кешу.

Для мене налаштування vm.admin_reserve_kbytes = 262144 робить саме це. Вбивця OOM втручається до того, як система повністю не реагує.

Інші відповіді мають хороші автоматичні рішення, але я вважаю, що це може бути корисно також включити SysRqключ, коли речі виходять з рук. За допомогою SysRqключа ви будете обробляти ядро ​​вручну, і ви можете робити такі речі, як безпечна перезавантаження (з SysRQ + REISUB), навіть якщо користувацька область повністю застигла.

Щоб дозволити ядро ​​прослуховувати запити, встановити kernel.sysrq = 1або включити лише ті функції, які ви, ймовірно, використовуєте за допомогою бітової маски ( тут задокументовано ). Наприклад kernel.sysrq = 244, увімкніть усі комбінації, необхідні для безпечної перезавантаження вище, а також ручне виклик вбивці OOM за допомогою SysRq + F.

Надійність не досягається низькими умовами пам’яті та вбивцею OOM.

Неправильно організовувати вечірку в шафі та розміщувати "прибирання моєї шафи" у вашому невеликому списку відтворення.

Чи можливо змусити вбивцю ООМ втручатися раніше?

Це призведе до небажаних побічних результатів, оскільки ви не маєте контролю над тим, що вбито.

Я намагаюся налаштувати свою систему розвитку на максимальну надійність.

Максимальна надійність передбачає тестування вашої системи та вдосконалення системи на основі цих тестів.

Просто налаштування випадкових речей нікуди не дінеться ...

Я відключив своп, оскільки для використання графічного інтерфейсу він здебільшого робить машину невідповідною таким чином, що більше не використовується. Тим не менш, якщо агресивні програми з’їдають пам’ять, деякі механізми, здається, вдаряють у тому, щоб максимально використати її за рахунок швидкості.

Через низькі умови пам'яті, відключення swap не покращить поведінку , це робить навпаки .

Щоб збільшити надійність у цій ситуації, додайте більше пам’яті, щоб ваша система була більш чуйною і не було випадкових процесів, що вбиваються без наміру користувача. Не слід вдаватися до низьких умов пам'яті та подібного механізму, особливо не в середовищі розробки ...

Не існує жодної операції заміни жорсткого диска, але система також не реагує.

Низькі умови пам’яті дійсно призводять до безвідповідальності, незалежно від того, маєте ви своп або ні.

Тож я хочу дозволити вбивці OOM вбитись до того, як система докладе особливих зусиль щодо збільшення пам'яті.

Особливі зусилля, які принесуть більше шкоди, ніж користі, як я пояснив вище. Натомість ви можете вбити процеси, які вам самі не потрібні, але, мабуть, ви не можете цього зробити, щоб OOM знищив потрібні вам процеси.

Чи можна налаштувати вбивцю OOM для дії, якщо, наприклад, менше 100 Мб вільної фізичної пам'яті?

Можливо, але ви отримаєте більшу віддачу від інвестицій, якщо просто придбаєте додаткову пам’ять, яка не дуже коштує в ці дні. Подумайте, що ви збираєтеся вдарити себе в ногу в довгостроковій перспективі, якщо будете продовжувати працювати в умовах низької пам'яті. OOM - це як пристав, він не допомагає вам, він допомагає ОС ...