Препятствуйте тому, чтобы Ubuntu заморозилась, даже если системная память является низкой
Иногда я работаю с огромными дампами данных, которые я хочу сохранить в памяти для обработки. Иногда я неверно рассчитываю объем памяти, который произведет моя программа, или отладчик умножает использование памяти на фактор, который превышает мою доступную память.
Каждый раз, когда я запускаю требующий много памяти процесс, это - то, что я ожидал бы от нормальной операционной системы: попытайтесь съесть всю свободную память, затем попросите, чтобы некоторые другие несущественные процессы приятно бросили некоторую память, в которой они не нуждаются, затем пишут для свопинга.
Вот то, что Ubuntu делает для меня: съешьте всю fre память, затем попросите, чтобы операционная система подкачала все важные услуги (сессия гнома, терминал, клавиатура), затем заморозьтесь и ожидайте меня для получения по запросу разъема питания.
Два вопроса:
- Как операционная система может принять, что что-нибудь могло быть столь важным, что нормально прекращать слушать ввод данных пользователем?
- Как я могу сказать Ubuntu никогда не подкачивать важные услуги и всегда реагировать на ввод данных пользователем, даже если некоторый глупый процесс пытается съесть больше ресурсов, чем система обеспечивает.
4 ответа
Ubuntu 16.04 поставлется с версией 4.4 ядра. В версии 4.6 Ядра уничтожитель OOM (Из Уничтожителя Задачи Памяти) имел главную перестройку для обращения к жалобам как Ваши. Версия 4.6 ядра в конце жизни, и текущая версия 4.7.2 Ядра Ubuntu находится на веб-сайте. Это устраняет много других проблем помимо обновления oom_reaper модуль.
я сделал тест на прошлой неделе, заполнив RAM +, ПОДКАЧИВАЮТ и вводят, остался стабильным. Мне также разрешили переключиться между активными окнами только с задержкой мини-Суле. Я не мог вызвать новый процесс, такой как 'высокий звук' + 'экран печати', но мог вызвать организованное завершение работы.
У меня все еще нет решения для проблемы, но я могу предложить два обходных решения, которые могли бы представлять интерес для других:
1) earlyoom
Это - сервис, который следит за использованием памяти и уничтожает процесс, который использует большую часть памяти, когда определенный порог достигнут (см. также это и этот вопрос относительно уничтожителя OOM в ядре Linux)
я протестировал его с демонстрационным процессом, который неограниченно долго запрашивает память в маленьких блоках. Вот мое первое впечатление: Когда я запускаю процесс жулика, он быстро съедает всю мою RAM. Затем свопинг начинается, система становится inresponsive. Несколько секунд спустя система назад онлайн. Журнал earlyoom показывает, что уничтожил пищевой процесс памяти после того, как и память и использование подкачки достигли 90%.
существует все еще раздражающая задержка, когда свопинг начинается и после того, как процесс был уничтожен, некоторые части других процессов обычно остаются в подкачке, пока их не требуют, но это - запуск.
2) просто отключают подкачку
, я знаю, что это спорная тема , но в целях настольных систем и особенно машин разработки, где это может время от времени происходить, что процесс пытается съесть всю Вашу память, он имеет смысл: Без подкачки уничтожитель OOM просто работает, как предназначено. Когда у Вас заканчивается память, она находит лучший процесс уничтожать и избавляется от него. Никакая задержка, никакая задержка.
можно отключить подкачку для текущей сессии с sudo swapoff -a, или делают изменение постоянным .
надлежащее решение для проблемы, конечно, состояло бы в том, что система остается быстро реагирующей, когда оперативная память истощается, и она начинает подкачивать память, любят существует не завтра, но этого, кажется, не происходит в ближайшее время.
Попробуйте одну из двух вещей:
1) изменяют swappiness, сходящий с его настройки по умолчанию 60, к 10, т.е.: добавьте vm.swappiness = 10 к/etc/sysctl.conf (в терминале, типе sudo gedit /etc/sysctl.conf), затем перезагрузите систему. Ищите здесь swappiness для большего количества информации об этом.
2), Если swappiness не помогает... даже при том, что Вы не можете хотеть... увеличивать размер своего своп-файла к 1.5x16G и видеть, помогает ли это.
Держат меня в курсе. С наилучшими пожеланиями, Al
Я решил подобную проблему. Я не знаю если мой опыт, возможно, подходящий для Вас...
Недавно я опубликовал руководство по тому, как установить Linux на обратной петле устройства LVM, загружающиеся от USB (таким образом, без должны установить личинку на внутреннем диске, оставив его как исходный). Вот руководство: https://github.com/DareDevil73/linux-on-loopback-usb.
Затем я упавший в замораживании выхожу на загрузке верхней памяти, и я наблюдал аварийное использование области подкачки (вся RAM, которую съели и использование подкачки рядом для обнуления). Очевидно, раздел подкачки LVM был смонтирован и работающий правильно, но я не делаю известный, почему ядро не использовало его как ожидалось.
Я попробовал альтернативное решение. Я создал петлевой файл подкачки (не LVM), и замораживания не стало. Теперь файл подкачки используется, как это было бы, и ОС никогда не замораживается!
Посмотрите на https://github.com/DareDevil73/linux-on-loopback-usb#known-issues для получения более глубокой информации.