В Ubuntu быстро заканчивается ОЗУ, и мой компьютер начинает зависать. Какая команда это решит?

По моему опыту, Firefox и Chrome используют больше RAM, чем мои первые 7 объединенных компьютеров. Вероятно, больше, чем это, но я убегаю от своей точки. Самая первая вещь, которую необходимо сделать, закрыть браузер. Команда?

killall -9 firefox google-chrome google-chrome-stable chromium-browser

Я связал самые популярные браузеры в одну команду там, но очевидно при выполнении чего-то еще (или знают, Вы не используете один из них), просто изменяют команду. killall -9 ... важный бит. Люди действительно становятся сомнительными о SIGKILL (сигнал номер 9), но браузеры чрезвычайно эластичен. Больше, чем это, завершаясь медленно через SIGTERM будет означать, что браузер делает загрузку мусора очистки — который требует пакета дополнительной RAM — и это - что-то, что Вы не можете позволить себе в этой ситуации.

Если Вы не можете получить это в уже рабочий терминал или диалог Alt+F2, рассмотрите переключение на TTY. Управление + Высокий звук + F2 получит Вас к TTY2, который должен позволить Вам входить в систему (хотя это могло бы быть медленно), и должен даже позволить Вам использовать что-то как htop отлаживать проблему. Я не думаю, что у меня когда-либо заканчивалась RAM к мысли, которую я не мог понять htop .

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

В системе с Волшебным Системным включенным Ключом Запроса, нажатие Alt + Системный Запрос + f (если не отмеченный на Вашей клавиатуре, Системный Запрос часто находится на клавише Print Screen) вручную вызовет ядро из уничтожителя памяти (oomkiller), который пытается выбрать худший незаконный процесс для использования памяти и уничтожить его. Можно сделать это, если у Вас есть, возможно, меньше времени, чем Вы описали, и система как раз собирается запуститься (или возможно уже запустился), перегружающийся - в этом случае Вы, вероятно, не заботитесь точно, что уничтожается, просто что Вы заканчиваете с применимой системой. Иногда это может закончить тем, что уничтожило X, но большую часть времени в эти дни это намного лучше в выборе плохого процесса, чем это раньше было.

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

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

Альтернативные решения:

• Увеличьте скорость чтения подкачки путем помещения раздела подкачки в RAID1
  • Или RAID0, если Вы чувствуете себя опасными, но это снизит большое количество запущения программ, если какой-либо из Ваших дисков будет неправильно функционировать.
• Сократите число параллельных заданий сборки ("больше ядер = больше скорости", говорим все мы, забывая, что это берет линейный сбор на RAM),
• Это могло пойти обоими путями, но попытаться включить zswap в ядре. Это сжимает страницы, прежде чем они будут отправлены в подкачку, которая может обеспечить как раз достаточно пространства для маневра для ускорения машины. С другой стороны, это могло только закончить тем, что было помехой с дополнительным сжатием/распаковкой, которое это делает.
• Выключите оптимизации или используйте другой компилятор. Оптимизация кода может иногда поднимать несколько гигабайтов памяти. Если у Вас есть включенный LTO, Вы собираетесь использовать много RAM на этапе ссылки также. Если все остальное перестало работать, можно попытаться компилировать проект с компилятором более легкого веса (например. tcc), за счет небольшого хита производительности во время выполнения к скомпилированному продукту. (Это обычно приемлемо при выполнении этого в целях разработки/отладки.)

Можно использовать следующую команду (неоднократно в случае необходимости) для уничтожения процесса с помощью большую часть RAM в системе:

ps -eo pid --no-headers --sort=-%mem | head -1 | xargs kill -9

С:

• ps -eo pid --no-headers --sort=-%mem: отобразите идентификаторы процесса всех рабочих процессов, отсортированных по использованию памяти
• head -1: только сохраните первую строку (процесс с помощью большую часть памяти)
• xargs kill -9: уничтожьте процесс

Редактирование после точного комментария Dmitry:

Это - быстрое и грязное решение, которое должно быть выполнено, когда нет никакого чувствительного выполнения задач (задачи, что Вы не хотите kill -9).

Прежде, чем выполнить Ваши команды потребления ресурса, Вы могли также использовать setrlimit (2) системный вызов, вероятно, с ulimit встроенный из Вашей оболочки удара (или limit встроенный в zsh) особенно с -v для RLIMIT_AS. Затем слишком большое потребление виртуального адресного пространства (например, с mmap (2) или sbrk (2) используемый malloc (3)) перестанет работать (с errno (3) являющийся ENOMEM).

Затем они (т.е. голодные процессы в Вашей оболочке после ввода ulimit) был бы завершен прежде, чем заморозить Вашу систему.

Читайте также Linux Съел Мою RAM, и рассмотрите чрезмерные обязательства памяти отключения (путем выполнения команды echo 0 > /proc/sys/vm/overcommit_memory как корень, см. proc (5)...).

Создайте еще некоторую подкачку для себя.

Следующее добавит 8G подкачки:

dd if=/dev/zero of=/root/moreswap bs=1M count=8192
mkswap /root/moreswap
swapon /root/moreswap

Это все еще будет медленно (Вы подкачиваете), но Вы не должны на самом деле выбегать. Современные версии Linux могут подкачать в файлы. О единственном использовании для раздела подкачки в эти дни для спящего режима Вашего ноутбука.

это происходит довольно часто со мной, когда я компилирую программное обеспечение в фоновом режиме

В этом случае что-то как "killall-9 делает" (или независимо от того, что Вы используете для управления компиляцией, если не делают). Это остановит компиляцию, продолжающуюся далее, будет SIGHUP все процессы компилятора, запущенные от нее (надо надеяться, то, чтобы заставлять их остановиться также) и, в качестве награды, не нуждается в sudo предположение, что Вы компилируете как тот же пользователь, Вы зарегистрированы как. И так как это уничтожает фактическую причину Вашей проблемы вместо Вашего веб-браузера, X сессий или некоторого процесса наугад, это не вмешается в то, что Вы делали в системе в то время.

sudo swapoff -a отключит подкачку, заставляя ядро автоматически уничтожить процесс с самым высоким счетом, если система исчерпает память. Я использую это, если я знаю, что буду выполнять что-то тяжелое RAM, которое я уничтожил бы, если оно выходит из-под контроля, чем позвольте ему войти в подкачку и застряньте навсегда. Использовать sudo swapon -a повторно включить его впоследствии.

Позже, можно хотеть смотреть на настройки подкачки. Кажется, что Ваша подкачка находится на том же диске как корневой раздел, который замедлил бы Вашу систему, когда Вы поражаете подкачку, поэтому избегайте этого, если Вы можете. Кроме того, по-моему, современные системы часто настраиваются со слишком большой подкачкой. 32 ГиБ RAM обычно означают, что подкачка на 32 ГиБ выделяется по умолчанию, как будто Вы действительно хотите поместить 32 ГиБ в свою область подкачки.

Один способ получить блок свободной RAM на коротком уведомлении состоит в том, чтобы использовать zram, который создает сжатый псевдодиск и подкачки там. С любым полудостойным ЦП это намного быстрее, чем регулярная подкачка, и показатели сжатия довольно высоки со многими современными пожирателями ресурсов RAM как веб-браузеры.

Принятие Вас имеет zram, установленный и настроенный, все, к чему необходимо сделать, выполняется

sudo service zramswap start

Другой вещи, которые можно было сделать, должен освободить кэш страницы памяти через эту команду:

echo 3 | sudo tee /proc/sys/vm/drop_caches

Из документации kernel.org (добавленный акцент):

drop_caches

Запись в это заставит ядро отбрасывать чистые кэши, а также исправимые объекты плиты как dentries и inodes. После того, как отброшенный, их память становится свободной.

Освободить pagecache: отзовитесь эхом 1>/proc/sys/vm/drop_caches Для освобождения исправимых объектов плиты (включает dentries и inodes): отзовитесь эхом 2>/proc/sys/vm/drop_caches К свободным объектам плиты и pagecache: отзовитесь эхом 3>/proc/sys/vm/drop_caches

Это - неразрушающая операция и не освободит грязных объектов. Для увеличения числа объектов, освобожденных этой операцией, пользователь может выполнить 'синхронизацию' до записи в/proc/sys/vm/drop_caches. Это минимизирует количество грязных объектов в системе и создаст больше кандидатов, чтобы быть отброшенным.

Вы сказали "компиляцию в фоновом режиме". Что Вы делаете на переднем плане? При разработке с Eclipse или другим ресурсом тяжелого IDE проверьте, завершается ли все правильно в консоли.

Среды разработки часто позволяют запускать несколько разрабатываемых процессов, они могут остаться зависающими также после того, как Вы больше не интересуетесь ими (в отладчике, или просто не правильно закончены). Если разработчик не обращает внимание, десятки процессов, о которых забывают, могут накопиться в течение дня, с помощью нескольких гигабайтов вместе.

Проверьте, завершается ли все, что должно быть завершено в IDE.

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

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