Назад | Перейти на главную страницу

Как предотвратить зависание Linux при нехватке памяти?

Сегодня я (случайно) запустил какую-то программу на своем Linux-компьютере, которая быстро использовала много памяти. Моя система зависла, перестала отвечать, и поэтому я не смог убить преступника.

Как я могу предотвратить это в будущем? Разве он не может хотя бы поддерживать работоспособное ядро ​​или что-то еще?

Готов поспорить, что система на самом деле не "зависла" (в том смысле, что ядро ​​зависло), а просто очень не отвечала. Скорее всего, это была просто очень сложная подкачка, из-за которой интерактивная производительность и пропускная способность системы упали как камень.

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

В качестве альтернативы вы можете использовать ограничения ресурсов для каждого процесса (обычно называемые rlimit и / или ulimit), чтобы исключить возможность того, что один процесс заберет невероятный объем памяти и вызовет подкачку, но это просто подтолкнет вас к интересной территории с процессами, которые умирают в неудобные моменты, потому что им нужно немного больше памяти, чем система была готова им предоставить.

Если бы вы знали, что собираетесь сделать что-то, что может вызвать массовое использование памяти, вы, вероятно, могли бы написать программу-оболочку, которая mlockall() а затем выполнить вашу оболочку; это сохранит его в памяти и будет наиболее близким к «поддержанию отзывчивого ядра», которое вы, вероятно, получите (потому что проблема не в том, что процессор перегружен).

Лично я поддерживаю метод управления ресурсами «не делай глупостей». Если у вас есть root, вы можете нанести любой ущерб системе, и так что-нибудь о вероятных результатах которого вы не знаете, - рискованный бизнес.

Как упоминалось выше в комментарии Tronic, можно вызвать OOM-killer (убийца нехватки памяти) напрямую с помощью комбинации клавиш SysRq-F.

SysRq ключ обычно объединяется в PrtSc ключ на клавиатуре.

OOM-killer убивает некоторые процессы, и система снова становится отзывчивой. Прямой доступ к OOM-killer не может быть включен по умолчанию, пожалуйста, проверьте этот вопрос чтобы узнать, как проверить его статус и / или включить его.

PS: Это мне очень помогло. Я согласен с мнением, что это самый полезный совет по поводу этой проблемы, если она вызвана Chrome или каким-либо другим программным обеспечением, требующим памяти. Но нужно иметь в виду, что OOM-killer может убить какой-то действительно важный процесс, используйте его осторожно.

Это ошибка, известная с 2007 года - см. Зависание системы при большом использовании памяти.

В этой ситуации Windows отображает диалоговое окно, предупреждающее пользователя о необходимости закрыть одно или несколько приложений.

Если вы хотите перекомпилировать ядро, вы можете попробовать патч из EDIT раздел этого вопроса: https://stackoverflow.com/q/52067753/10239615
Это не выселяет Active(file) страниц во время высокого давления памяти и, таким образом, позволяет OOM-killer запускаться почти мгновенно, потому что ядру больше не нужно тратить минуты на постоянное перечитывание с диска исполняемых кодовых страниц каждого процесса, вызывающее зависание ОС.

Это особенно сложно предотвратить. Это потому, что ядро ​​начинает подкачку. Одно из решений - отключить свопинг. Когда в системе заканчивается память, ядро ​​не запускает свопинг, а завершает некоторые процессы; обычно он выбирает правильный процесс для уничтожения, но в любом случае лучше убить случайный процесс, чем иметь неотвечающую систему.

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