Вбивця OOM не працює належним чином, призводить до застигання ОС

Роками вбивця OOM моєї операційної системи не працює належним чином і призводить до застиглої системи.
Коли об'єм пам'яті дуже високий, вся система має тенденцію до «заморожування» (насправді: стає надзвичайно повільним) годинами чи навіть днями , замість того, щоб вбивати процеси звільнення пам'яті.
Максимум, що я записав, - це 7 днів, перш ніж подати у відставку, щоб виконати скидання.
Коли очікується досягнення ООМ, іовітація дуже велика (~ 70%), перш ніж стати незмірною.
Інструмент: iotopпоказав, що всі програми читаються з дуже високою пропускною здатністю (на десятки МБ / сек) з мого жорсткого диска.
Що читають ці програми?
- Ієрархія каталогів?
- Сам виконуваний код?
Я зараз не точно.

[відредаговано] У той час, коли я писав це повідомлення (у 2017 році), я використовував оновлений ArchLinux (4.9.27-1-lts), але вже випробовував цю проблему роками раніше.
У мене виникли ті ж проблеми з різними дистрибутивами Linux та різними конфігураціями апаратних засобів.
В даний час (2019 р.) Я використовую оновлений Debian 9.6 (4.9.0). У мене є 16 Гб фізичного оперативної пам’яті, SSD, на якому встановлена ​​моя ОС, а не будь-який розділ swap .

Через кількість оперативної пам’яті, яку я маю, я не хочу вмикати розділ swap, оскільки це просто затримає присутність проблеми.
Крім того, якщо заміни SSD занадто часто можуть потенційно скоротити термін служби диска.
До речі, я вже пробував з розділом swap і без нього, він виявив, що лише затримує уявлення про проблему, але не є рішенням.

Для мене проблема викликана тим, що Linux скидає основні дані з кеш-пам'ять , що призводить до застиглої системи, оскільки вона має читати все щоразу з жорсткого диска.

Мені навіть цікаво, чи Linux не відкине виконувані кодові сторінки запущених програм, що пояснить, чому програми, які зазвичай не читають багато даних, так поводяться в цій ситуації.

Я спробував кілька речей, сподіваючись виправити це питання.
Один з них був встановити , /proc/sys/vm/min_free_kbytesщоб 1000000(1 GB).
Оскільки цей 1 Гб повинен залишатися вільним, я думав, що ця пам’ять буде зарезервована Linux для кешування важливих даних.
Але це не спрацювало.

Крім того , я думаю , корисно додати , що навіть якщо це може здатися великою в теорії, обмежуючи розмір віртуальної пам'яті до розміру фізичної пам'яті, визначивши /proc/sys/vm/overcommit_memoryдля 2непристойно технічно можливо в моїй ситуації, так як вид додатків що я використовую, вимагають більше віртуальної пам'яті, ніж вони ефективно використовують з якихось причин.
Згідно з файлом /proc/meminfo, це Commited_ASзначення часто вище, ніж удвічі фізичного барана в моїй системі (16 ГБ, Commited_AS часто> 32 ГБ).

Я відчував цю проблему з /proc/sys/vm/overcommit_memoryїї значенням за замовчуванням:, 0і деякий час я визначив це:, 1тому що я вважав за краще, щоб програми були вбиті вбивцею OOM, а не поводилися неправильно, оскільки вони не перевіряють значення повернення, mallocколи асигнування відмовляються.

Коли я говорив про цю проблему в IRC , я зустрів інших користувачів Linux, які відчули цю саму проблему, тому я здогадуюсь, що багато користувачів переймаються цією проблемою.
Для мене це не прийнятно, оскільки навіть Windows краще справляється з високим рівнем використання пам'яті.

Якщо вам потрібна додаткова інформація, є пропозиція, будь ласка, скажіть мені.

Документація:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm. txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/

Вони говорять про це:
Чому вбивця поза пам'яті Linux (OOM) не працює автоматично, а працює на ключі sysrq?
Чому іноді вбивця OOM не вдається вбити ресурсних свиней?
Попереднє завантаження вбивці OOM
Чи можливо запустити вбивцю OOM при примусовій заміні?
Як уникнути високої затримки біля ситуації з ООМ?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843

Я знайшов два пояснення (того ж самого) щодо того, чому kswapd0 робить постійне читання диска, відбувається задовго до того, як OOM-убивця вбиває процес, що порушує:

1. див. відповідь та коментар до цієї відповіді askubuntu SE
2. див. відповідь та коментарі Девіда Шварца до цієї відповіді на unix SE

Я цитую тут коментар від 1., який справді відкрив мені очі на те, чому я отримую постійне читання диска, коли все застигло :

Наприклад, розглянемо випадок, коли у вас немає нульового свопу, а в системі майже не вистачає оперативної пам’яті. Ядро займе пам'ять, наприклад, Firefox (це може зробити, тому що Firefox працює виконуваним кодом, завантаженим з диска - при необхідності код можна знову завантажити з диска). Якщо Firefox потім повинен отримати доступ до цієї оперативної пам’яті знову через N секунд, процесор генерує «жорстку помилку», яка змушує Linux звільнити деяку оперативну пам’ять (наприклад, взяти деяку оперативну пам’ять з іншого процесу), завантажити завантажені дані з диска і потім дозволити Firefox продовжувати як звичайний. Це досить схоже на звичайний своп і kswapd0 робить це. - Мікко Ранталайнен 15 лютого о 13:08

Якщо у когось є спосіб, як відключити цю поведінку (можливо, перекомпілюйте ядро ​​з якими варіантами? ), Будь ласка, повідомте мене якнайшвидше! Дуже вдячний, спасибі!

UPDATE: Єдиний спосіб я знайшов до сих пір через виправлення ядра, і це працює для мене своп відключеного (тобто. , CONFIG_SWAP is not setАле не працює для другіхов з свопом дозволив їй) здається ; див. виправлення всередині цього питання.

memory.minПараметр в cgroups-v2пам'яті контролера має допомогти.

А саме, дозвольте мені процитувати:

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

Джерело: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html