Система зависает при нехватке памяти

34

У меня есть eeePC 900a: он имеет 8 ГБ флэш-памяти и только 1 ГБ оперативной памяти. Установленный дистрибутив Linux - это ArchLinux.

Когда система исчерпывает память, она становится крайне не отвечающей: для таких вещей, как переключение на TTY1 или даже перемещение указателя мыши, уходит несколько секунд / минут. Иногда кажется, что система просто зависает: три года назад я оставил ее в покое, и пока ничего не изменилось.

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

Разве ядро ​​не должно убивать некоторые случайные приложения, когда ему не хватает памяти? Почему это не удается (или занимает много времени) при этом?

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

linux memory freeze peoro
источник
1
Какие DE / WM вы используете в своих настройках, какие сервисы / демоны вы используете? Использование полнофункциональной настольной среды и просмотр, например, с помощью Chromium или Firefox пожирает вашу оперативную память для позднего завтрака. 1 ГБ ОЗУ должно быть достаточно для запуска самого Arch Linux, но на самом деле важно то, что вы поставили поверх него.
1
Я использую LXDE. Хром это программа, которая обычно занимает большую часть оперативной памяти. Во всяком случае, это не главное. Не я должен заботиться о том, сколько памяти использует моя система, а моя система не должна умирать из-за этого. Если моей системе не хватает памяти, она может убить любое приложение, какое захочет, я просто хочу, чтобы оно не зависало !
peoro
6
Я имею в виду, я серьезно думал о запуске сценария , как это (в псевдокоде): while(true){ if( $FREE_MEMORY<10MB ){ kill -9 $RANDOM_PID; } }. Это определенно решило бы мою проблему. Но подождите, разве ядро ​​не должно делать это (и гораздо лучше, чем мой скрипт)? Почему он не делает свою работу?
peoro
2
@ Марчин, это только решит проблему, но не решит ее. Даже если бы у меня было 4 ГБ памяти (благодаря некоторому обмену), моя система могла бы исчерпать память (таким образом зависая). Чего я хочу избежать, так это того, что моя система зависает, когда в ней недостаточно оперативной памяти. Если бы мое ядро ​​внезапно убило хром, как только закончится ОЗУ, я был бы счастлив даже с теми 1 ГБ, которые у меня есть.
peoro
4
@Lee "magic sysrq" - это ключевая комбинация, которая идет непосредственно к ядру. Это часто будет работать, даже если клавиатура и мышь не отвечают. См. En.wikipedia.org/wiki/Magic_SysRq_key
Раман

Ответы:

14

OOM-killer (вне памяти) можно вызвать напрямую с помощью комбинации клавиш:

SysRq-F

Клавиша SysRq обычно сочетается с клавишей PrtSc на клавиатурах.

OOM-killer убивает некоторые процессы, и система снова становится отзывчивой.

Спасибо Раману за советы по этой функции в комментариях выше.

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

Arkemlar
источник
2
У меня есть ключ PrtScn|SysRq. Но нажатие SysRq - Fдает только скриншот
Lee
2
Поскольку вы в основном взяли мой комментарий выше и сделали его ответом, небольшая атрибуция была бы хорошей. Я все равно проголосовал за тебя. :-)
Раман
3
@ Ли. Вы должны включить его. В некоторых дистрибутивах по умолчанию не включена функция Magic Sysrq. Это должно помочь: google.ca/search?q=sysrq+enable
Раман
2
@Raman Бьюсь об заклад, 99%, которые считают, что это не может "включить его" по умолчанию, потому что их машина уже заморожена ... почему она не включена по умолчанию?
Фесихай
3
@themihai, потому что многие считают это угрозой безопасности - он дает вам прямой доступ к ядру через физический доступ к устройству ввода, независимо от состояния приложения, например, экранов блокировки и тому подобное.
Раман
12

Естественное положение вещей заключается в том, что данные приложения находятся в оперативной памяти, а файлы - на диске.
Идеально с точки зрения производительности - данные, которые часто используются, находятся в оперативной памяти, а данные, которые в данный момент не нужны, находятся на диске.
В нормальной системе ядро ​​делает две вещи, пытаясь достичь этого идеала:

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

В типичной системе значительная часть оперативной памяти отводится кэш-памяти и буферам (50% - это типичная цифра). Поскольку ОЗУ является ограниченным ресурсом, для этого может потребоваться смещение некоторых данных приложения для подкачки (подкачка необходима, только если есть лучший способ использования ОЗУ).

В системе без подкачки есть момент, когда данные приложения используют почти всю оперативную память, и поэтому для кеша практически не остается места. Тогда система, вероятно, будет медленной. Ядро не начнет убивать приложения до тех пор, пока это не произойдет. Пока приложения заполняют только 99% доступной памяти, система продолжает работать, но очень медленно, потому что данные файлов должны постоянно загружаться и перезагружаться с диска. С теми же запущенными приложениями система будет быстрее со свопом в этот момент.

Для получения дополнительной информации по этому вопросу см. Обсуждение lkml и эту запись в блоге .

Я не знаю прямого способа сказать ядру зарезервировать минимальный объем оперативной памяти для дискового кэша. Вы можете настроить небольшую часть вашей оперативной памяти как пространство подкачки , возможно, даже сжатую . На этом фронте есть сообщения об успехах , хотя я не даю никаких гарантий в вашем конкретном случае.

Жиль "ТАК - прекрати быть злым"
источник
1
Спасибо за объяснение и ссылки, они помогли прояснить некоторые сомнения по поводу обмена. После ответа @Marcin на мой вопрос я установил 256 МБ сжатого виртуального свопа (compcache) в моей оперативной памяти. Это, однако, не полностью отвечает на мой вопрос: я понимаю, что моя система будет работать медленно, когда вся оперативная память используется только приложением и ничего не кэшируется; Тем не менее я не могу понять, почему эта система зависает в течение нескольких минут / часов (может быть, навсегда?), Когда у меня полностью не хватает оперативной памяти. Я думаю, что мое ядро ​​не выполняет свою работу по уничтожению приложений, когда не хватает памяти, если для переключения на TTY1 недостаточно 3 часов.
peoro
У меня отключен режим подкачки с 32 ГБ физической памяти, и когда плохое программное обеспечение убегает с выделением памяти (привет ld, кусок мусора), оно все еще зависает почти минуту, просыпаясь настолько, чтобы позволить мне на секунду двигать невероятно медленную мышь или два каждые несколько секунд. Обработка OOM в Linux - полная хрень. Если мне повезет, OOM Killer убивает правильный процесс, не нарушая полностью среду рабочего стола. И я большой поклонник Linux. Это намного хуже с включенной подкачкой. Linux-пейджинг - это шутка.
doug65536
6

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

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

Дан Дакалеску
источник
2
Кажется, что "Unassigned" в Ubuntu. Возможно, DE должен предупредить пользователя или даже заморозить приложение, интенсивно использующее память?
nkkollaw
1
@nbrogi - ничего, кроме тихого замораживания. Но удачи в том, чтобы убедить разработчиков Ubuntu сделать это.
Дан Даскалеску
6

Недавно я нашел решение моей проблемы.

Поскольку Linux OOM Killer не может выполнять свою работу должным образом, я начал использовать пользовательское пространство OOM Killer: earlyoom . Он написан на C, довольно настраиваемый и работает для меня как шарм.

Я также слышал о некоторых альтернативах, таких как OOMD Facebook , разработанных для запуска на их серверах, но я не пробовал этот

peoro
источник