Да, это широкий вопрос, но я бы сказал, вполне обоснованный. Иногда программы и сценарии занимают слишком много времени или используют слишком много памяти и действительно начинают тормозить мою систему. Хорошо. Иногда система тормозит так сильно, что я едва могу показать свою мышь в терминале и спамить Ctrl+C. Меня сбивает с толку то, почему ОС не дает приоритета планирования, чтобы позволить пользователю использовать мышь, клавиатуру и убивать вещи. Вы когда-нибудь видели это?
> ./program
^C^C^C^C^C^C^C^C^C^C^C^Z^Z^Z^C^C^C^C^C^Clsdhafjkasdf
Теперь Ctrl+C не такой строгий, как некоторые другие (он может обрабатываться приложением и даже игнорироваться, но здесь это не так). Ctrl+Z тоже неплохо бы справился, так как я мог бы сразу kill -9 %1 но это тоже не сработало.
Другой способ может заключаться в том, чтобы перейти к виртуальной консоли Ctrl+Alt+F2, войти в систему и завершить работу приложения-нарушителя, но поскольку система занята, это не работает, и я получаю черный экран. Также я не могу открыть новые терминалы (окно всплывает, но не может бросить меня в оболочку). Другие открытые терминалы могут не отвечать или запускать команды.
Я подозреваю, что одна из причин, по которой система так неработоспособна, заключается в том, что программа-нарушитель запускает функцию свопинга и выталкивает больше основных приложений из основной памяти. Даже самая простая команда, чтобы дать мне приглашение bash или выполнить kill, не может получить цикл на ребре. У меня нет доказательств этого , потому что я не могу бежать top , когда это произойдет. Есть ли варианты, чтобы улучшить шансы оригинального Ctrl+C работает? , Может быть, что-то вроде увеличения X и терминального приоритета или автоматического уничтожения программ, которые используют большую часть памяти или начинают переставлять слишком много?
Есть ли другой linux-fu, который я мог бы использовать, чтобы восстановить контроль, когда это происходит (например, команды SysRq )?
Обновление: после нескольких тестов я почти уверен, что приложения используют слишком много памяти и переключаются. Даже после того, как приложение было убито, другим нужно очень много времени, чтобы начать реагировать, как если бы они были вытеснены из основной памяти. Мне бы очень хотелось, чтобы какой-то способ автоматически ограничивал использование программ с большим объемом памяти основной памятью. Если он достигнет свопа, он все равно будет слишком медленным, поэтому какой смысл продолжать его.
ПРИМЕЧАНИЕ: я не ищу решение для конкретного приложения и не знаю заранее, когда какая-то операция собирается сжечь память. Я хочу решить этот вид замедления всей системы. Т.е. многие программы вызывают это. AFAIK Я не испортил конфигурацию системы, и это довольно стандартная установка Fedora. Я не удивлен этими замедлениями, но я хочу больше контроля.
Я хотел бы, чтобы мой оконный менеджер работал, и это мои последние курорты, которых я надеюсь избежать. Как правило, они нужны только в том случае, если мой графический процессор застрял в цикле и блокирует X. Если этот параметр включен, Ctrl+Alt+backspace - это удобное сочетание клавиш для удаления X и всех ваших приложений, возвращающее вас к входу в систему. Более мощная команда, опять же, если она включена, это Alt+SysRq+K. Если это не работает, он удерживает кнопку питания во времени.
Alt+SysRq+F (спасибо, @Hastur), который убивает процессы захвата памяти, довольно разрушителен, но может помочь в качестве последнего средства.
Обновление: Не совсем уверен во всех последствиях здесь, но предложение ulimit @ Xen2050, похоже, решает многие проблемы ...
TOTAL_PHYSICAL_MEMORY=$(grep MemTotal /proc/meminfo | awk '{print $2}')
ulimit -Sv $(( $TOTAL_PHYSICAL_MEMORY * 4 / 8))
Собираюсь оставить это в моем bashrc и посмотреть, как идут дела.
Обновление: в основном все выглядит хорошо, за исключением, я думаю, некоторых приложений, которые используют большие библиотеки и отображают большие файлы. Даже если они потребляют только какую-то фактическую память и вряд ли будут часто менять своп. Кажется, не хватает числа, достаточного для того, чтобы убить смертельно опасные приложения подкачки, но оставьте работающими обычные (такие как 4.6 ГБ VIRT amarok).
Связанный: https://unix.stackexchange.com/questions/134414/how-to-limit-the-total-resources-memory-of-a-process-and-its-children/174894, но по-прежнему проблема ограничения приложения, которые начинают бить, меняются местами.
Это именно то решение, которое, как выясняется, мне нужно: возможно ли заставить убийцу ООМ вмешаться раньше?