Возможно ли заставить убийцу ООМ вмешаться раньше?

Я также боролся с этой проблемой. Я просто хочу, чтобы моя система оставалась отзывчивой, несмотря ни на что, и я предпочитаю потерять процессы, чтобы подождать несколько минут. Кажется, нет никакого способа достичь этого, используя kernel oom killer.

однако в пользовательском пространстве мы можем делать все, что захотим. Поэтому я написал ранний Демон OOM ( https://github.com/rfjakob/earlyoom ), что убьет крупнейший процесса (по RSS), когда оперативной памяти становится меньше 10%.

без earlyoom, было легко запереть мою машину (8 ГБ оперативной памяти), запустив http://www.unrealengine.com/html5/ несколько раз. Теперь, виновные вкладки браузера убивают, прежде чем все выйдет из-под контроля.

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

Вы можете изменить политику, чтобы запретить перерасход памяти, записав значение 2 /proc/sys/vm/overcommit_memory. Значение по умолчанию /proc/sys/vm/overcommit_ratio 50, поэтому ядро не позволит приложениям выделять более 50% ОЗУ+своп. Если у вас нет подкачки, то ядро не позволит приложениям выделять более 50% оперативной памяти, оставляя остальные 50% свободными для кэша. Это может быть немного чрезмерно, так что вы можете увеличить это значение, скажем, 85% или около того, так что приложения могут выделить до 85% оперативной памяти, оставляя 15% для кэша.

для меня настройка vm.admin_reserve_kbytes=262144 делает именно это. Intervents убийца ООМ, прежде чем система полностью не отвечает.

другие ответы имеют хорошие автоматические решения, но я считаю, что может быть полезно также включить SysRq ключ для Когда вещи выходят из-под контроля. С SysRq ключ, вы бы вручную сообщениями ядра, и вы можете делать такие вещи, как безопасной перезагрузки (с SysRQ + REISUB) даже если пользовательское полностью заморожены.

чтобы разрешить ядру прослушивать запросы, установите kernel.sysrq = 1, или включить только те функции, которые вы, вероятно, будете использовать с битовой маской (документировано здесь). Для пример kernel.sysrq = 244 позволит все комбо, необходимые для безопасной перезагрузки выше, а также ручной вызов убийцы OOM с SysRq + F.