Linux без подкачки все равно начинает тормозить

Linux без подкачки все равно начинает тормозить

Debian 9.4, Linux 4.9

Иногда я компилирую что-то, что едва помещается в ОЗУ, или какой-то мошеннический процесс внезапно начинает потреблять память сверх доступной. Когда процесс выходит за пределы доступной ОЗУ, Linux начинает долбить диск, даже если у меня включен нулевой своп (без свопа — это попытка избежать этого). Полагаю, он начинает отбрасывать и перезагружать что-то вроде ped- mmapчастей исполняемых в данный момент двоичных файлов?

В этот момент мой сеанс X быстро перестает отвечать на запросы, и все, что мне остается, это ждать десятки минут, пока весь сеанс X не будет завершен, и я не смогу снова войти в систему.

Я пытался искать решения, но ничего не работает. OOM killer не ловит этот процесс, и vm.overcommit_memory=2я даже не могу войти в GDM и Gnome.

Есть ли способ?чтобы сказать Linux не производить подкачку вообще? Таким образом, у меня, по крайней мере, будет шанс, что процесс rouge будет прерван неудачным malloc, а даже если и нет, мне, по крайней мере, не придется ждать, глядя на неотвечающую машину.

Или есть какие-нибудь другие подсказки, как справиться с этой ситуацией?

решение1

Если вы компилируете исходники, которым требуется почти вся доступная оперативная память, если не больше, то, вероятно, единственным производительным решением будет добавление реальной оперативной памяти. Сказав это, вы можете попробовать добавить очень большой объем подкачки (скажем, в 2 или 3 раза больше оперативной памяти) и установить /proc/sys/vm/swappinessнизкое значение, например 1 (обратите внимание, что с ядром 3.5+ установка его в 0 полностью отключает подкачку), так что подкачка будет использоваться только при фактической необходимости. Это должно минимизировать пробуксовку.

решение2

Я не понимаю, как люди могут рекомендовать добавлять больше оперативной памяти или больше места подкачки. Неправильно работающее приложение может съесть все и воспроизвести проблему.

Такого рода зависания являются серьезной архитектурной ошибкой в ​​ядре Linux. Единственный способ восстановиться после зависания — принудительно вызвать OOM с помощью волшебной клавиши (alt+sysrq+f). Журнал ядра позже сообщит вам, что было убито и почему.

Несколько проектов пытаются предотвратить это зависание из пользовательского пространства. См. пример earlyOOM.

Связанный контент