OOM killer не работает должным образом, приводит к зависанию ОС

В течение многих лет OOM убийца моей операционной системы не работает должным образом и приводит к зависанию системы.
Когда использование памяти очень велико, вся система имеет тенденцию «зависать» (на самом деле: становиться очень медленной) в течение нескольких часов или даже дней , вместо того, чтобы убивать процессы для освобождения памяти.
Максимум, что я записал, составляет 7 дней до того, как я смирился с необходимостью выполнить сброс.
Когда OOM собирается быть достигнутым, Iowait очень очень высок (~ 70%), прежде чем стать неизмеримым.
Инструмент: iotopпоказал, что каждая программа читает с очень высокой пропускной способностью (на десятки МБ / с) с моего жесткого диска.
Что эти программы читают?
- иерархия каталогов?
- сам исполняемый код?
Я не совсем сейчас.

[отредактировано] В то время, когда я писал это сообщение (в 2017 году), я использовал обновление ArchLinux (4.9.27-1-lts), но уже сталкивался с этой проблемой в течение многих лет.
У меня возникла та же проблема с различными дистрибутивами Linux и различными конфигурациями оборудования.
В настоящее время (2019) я использую обновленную версию Debian 9.6 (4.9.0), у меня 16 ГБ физического ОЗУ, твердотельный накопитель, на котором установлена ​​моя ОС, а не раздел подкачки .

Из-за количества оперативной памяти, которую я имею, я не хочу включать раздел подкачки, так как это только задержит появление проблемы.
Кроме того, слишком частая замена SSD может потенциально сократить срок службы диска.
Кстати, я уже пробовал с разделом подкачки и без него, оказалось, что он только задерживает появление проблемы, но не является решением.

Для меня проблема вызвана тем фактом, что 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-key?
Почему OOM-killer иногда не может убить боровов с ресурсами?
Предварительная загрузка OOM Killer
Можно ли запустить OOM Killer при принудительной замене?
Как избежать высокой задержки в ситуации с OOM?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843

Я нашел два объяснения (одного и те же), почему kswapd0 делает чтение постоянного диска происходит задолго до того, ОАЯ-убийца убивает процесс обижая:

1. см. ответ и комментарий к этому ответу аскубунту SE
2. см. ответ и комментарии Дэвида Шварца к этому ответу на Unix SE

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

Например, рассмотрим случай, когда у вас нулевой своп, и системе почти не хватает ОЗУ. Ядро будет извлекать память, например, из Firefox (это можно сделать, потому что Firefox запускает исполняемый код, который был загружен с диска - код может быть загружен с диска снова, если это необходимо). Если затем Firefox необходимо снова получить доступ к этой ОЗУ через N секунд, ЦП генерирует «серьезный сбой», который вынуждает Linux освободить часть ОЗУ (например, извлечь часть ОЗУ из другого процесса), загрузить недостающие данные с диска и затем позволить Firefox продолжить работу как обычный. Это очень похоже на обычный обмен, и kswapd0 делает это. - Микко Ранталайнен 15 февраля в 13:08

Если у кого-то есть способ отключить это поведение (возможно, перекомпилировать ядро ​​с какими опциями? ), Пожалуйста, дайте мне знать как можно скорее! Высоко ценится, спасибо!

ОБНОВЛЕНИЕ: единственный способ, который я нашел до сих пор, - это исправление ядра, и оно работает для меня с отключенным свопом (т.е. CONFIG_SWAP is not set), но не работает для других с активированным свопом, кажется ; посмотрите патч внутри этого вопроса.

memory.minПараметр в cgroups-v2памяти контроллера должно помочь.

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

Жесткая защита памяти. Если использование памяти cgroup находится в пределах ее эффективной минимальной границы, память cgroup не будет восстановлена ​​ни при каких условиях. Если нет доступной незащищенной доступной памяти, вызывается OOM killer.

Источник: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html.