Линукс без свопа все равно начинает биться
Debian 9.4, Linux 4.9
Я иногда компилирую что-то, что едва умещается в ОЗУ, или процесс румян внезапно начинает поглощать память сверх того, что доступно. Когда процесс проходит через доступную оперативную память, Linux начинает перебивать диск, даже если у меня включен нулевой своп (никакой своп не был попыткой избежать этого). Я думаю, это начинает отбрасывать и перезагружать такие вещи, как mmapпед части тех двоичных файлов, которые в данный момент запущены?
На этом этапе мой сеанс X быстро перестает отвечать, и все, что я могу сделать, это подождать десятки минут, пока весь сеанс X не будет уничтожен, и я смогу снова войти в систему.
Я пытался найти решения, но ничего не помогло. Убийца OOM не ловит этот процесс и с vm.overcommit_memory=2 Я даже не могу войти с GDM и Gnome.
Есть ли способ сказать Linux не менять местами вообще? Таким образом, я бы по крайней мере получил шанс, что процесс румян будет убит неудачным mallocи даже если нет, по крайней мере, мне не нужно было бы ждать, глядя на неотзывчивую машину.
Или какие-то другие советы, как управлять этим сценарием?
2 ответа
Если вы компилируете источники, которые требуют почти всей доступной оперативной памяти, если не больше, вероятно, единственное эффективное решение - это добавление реальной оперативной памяти. Сказав это, вы можете попытаться добавить очень большой объем подкачки (скажем, 2x или 3x RAM) и установить /proc/sys/vm/swappiness до низкого значения, например 1 (обратите внимание, что в ядре 3.5+ установка его в 0 полностью отключает своп), так что своп используется только при необходимости. Это должно минимизировать побои.
Я не понимаю, как люди могут рекомендовать добавить больше оперативной памяти или места подкачки. Неправильно работающее приложение может съесть все это и воспроизвести проблему.
Подобные зависания являются серьезной архитектурной ошибкой ядра Linux. Единственный способ восстановиться после зависания — принудительно запустить OOM с помощью волшебной клавиши (alt+sysrq+f). Журнал ядра сообщит вам позже, что было убито и почему.
Несколько проектов пытаются предотвратить это зависание пользовательского пространства. См., например, EarlyOOM.