Это, вероятно, настолько очевидно, что Вы уже проверили, но Вы никогда не знаете.
Вы - использование случайно использование схемы конфигурации разделения?
В этом случае необходимо проигнорировать exim4.conf.template и пойти с/etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs вместо этого.
Готов поспорить, что система на самом деле не "зависла" (в том смысле, что ядро зависло), а просто очень не отвечала. Скорее всего, это был просто очень жесткий свопинг, в результате чего интерактивная производительность и пропускная способность системы упали, как камень.
Вы могли отключить свопинг, но это просто меняет проблему с низкой производительности на процессы, убитые OOM (и все развлечения, которые это вызывает), а также снижение производительности из-за менее доступного дискового кеша.
В качестве альтернативы вы можете использовать ограничения ресурсов для каждого процесса (обычно называемые rlimit
и / или ] ulimit
), чтобы исключить возможность того, что один процесс займёт невероятное количество памяти и вызовет свопинг, но это просто толкает вас на интересную территорию с процессами, которые умирают в неудобные моменты, потому что им нужно немного больше памяти, чем система была готова им предоставить.
Если бы вы знали, что собираетесь сделать что-то, что могло вызвать большой объем памяти использования, вы, вероятно, могли бы написать программу-оболочку, которая выполняла mlockall ()
, а затем запускала вашу оболочку; это сохранит его в памяти и будет наиболее близким к «поддержанию отзывчивого ядра», которое вы, вероятно, получите (потому что проблема не в том, что процессор перегружен, это проблема).
Лично я подписываюсь на к методу управления ресурсами «не делай глупостей». Если у вас есть root-права, вы можете нанести любой ущерб системе, делая все , что вы не делаете »
Это особенно сложно предотвратить. Это потому, что ядро начинает подкачку. Одно из решений - отключить свопинг. Когда в системе заканчивается память, ядро не запускает свопинг, а завершает некоторые процессы; обычно он выбирает правильный процесс для уничтожения, но в любом случае лучше убить случайный процесс, чем иметь неотвечающую систему.
Это может быть особенно хорошим решением для серверов, потому что у серверов часто достаточно оперативной памяти и при запуске использование пространства подкачки в любом случае означает, что что-то не так. Однако десктопам обычно требуется место подкачки, поэтому я думаю, что для десктопов нет хорошего решения. Я часто отключаю пространство подкачки на серверах, особенно когда есть подозрение на утечку памяти.
Это известная ошибка с 2007 г. - см. Зависание системы из-за высокого использования памяти .
В этой ситуации Windows отображает диалоговое окно, предупреждающее пользователя закрыть одно или несколько приложений.
Как упоминалось выше в комментарии Tronic, можно вызвать OOM-killer (убийцу нехватки памяти) напрямую с помощью комбинации клавиатуры SysRq - F .
Клавиша SysRq обычно объединяется с клавишей PrtSc на клавиатуре.
OOM-killer убивает некоторые процессы, и система снова становится отзывчивой. Прямой доступ к OOM-killer не может быть включен по умолчанию, пожалуйста, ознакомьтесь с этим вопросом , чтобы узнать, как проверить его статус и / или включить его.
PS: Это мне очень помогло. Я согласен с мнением, что это самый полезный совет по поводу этой проблемы, если она вызвана Chrome или каким-либо другим программным обеспечением, требующим памяти. Но нужно помнить, что OOM-killer может убить какой-то действительно важный процесс, используйте его осторожно.
Если вы хотите перекомпилировать ядро, вы можете попробовать патч из раздела EDIT
этого вопроса: https://stackoverflow.com/q/52067753/10239615
Он не вытесняет страницы Active (файл)
во время высокой нагрузки на память и, таким образом, позволяет OOM-killer запускаться почти мгновенно, потому что ядру больше не нужно тратить минуты на постоянное перечитывание с диска исполняемых кодовых страниц каждого процесса, вызывающих зависание ОС.
Вы можете использовать демона, такого как earlyoom, который проверяет подкачку и доступную оперативную память, вы можете настроить объем доступной памяти, как оперативной, так и подкачки, затем, если произойдет это пороговое значение, он убьет самую большую память едок, который обычно является виновным едоком, у вас также может быть список исключений, если вы этого хотите.