Зависание намертво, после того, как кончается память.
Мне это уже надоело, как только забивается вся оперативка, система виснет намертво. Почему не приходит OOM Killer? Если вручную по sysrq его вызвать, он прибивает офигевшие приложения (привет, chromium).
Почему не использовать своп?
Можно и использовать, интересует, почему киллер не приходит?
Нанять киллера — дороже чем курьера (:
Может, ему не хватает памяти?
Уже несколько лет как не актуально дрожать над их ресурсом.
какое ядро? какой дистр?
Он же вроде не сразу процесс убивает, надо подождать маленько.
OOM Killer при исчерпании свопа приходит через полчаса, либо добавь больше свопа, так, чтобы его хватало для комфортной работы (для приложений, активно использующих большие объёмы памяти, это плохой вариант), либо отключи его, виснуть перестанет, зато регулярно будет что-нибудь внезапно падать.
Ну во всяком случае я наблюдал такое лично, с тех пор у меня памяти больше, чем мне нужно, а хромиумом с его 12 гб на вкладку не пользуюсь более.
Дистрибутив особо не важен ИМХО, т.к. тоже самое было и на генте. Сейчас ARCH. Ядро
Linux lucille 3.17.1-1-ARCH #1 SMP PREEMPT Wed Oct 15 15:04:35 CEST 2014 x86_64 GNU/Linux
Полчаса, говорите, хм. Надо будет попробовать подождать, просто, когда-то, я тоже подумал, что надо ждать, оставил комп на ночь, утром пришёл, всё также висит. Свопа у меня вообще нету.
Это зависит от скорости работы дисковой подсистемы и объёма свопа. А в том случае вероятно была паника.
А ядро под такой момент тюнено?
vm.swapiness например.
Нет. Какие параметры порекомендуете?
Уже назвал, поставь его в 0.
Мне это уже надоело, как только забивается вся оперативка, система виснет намертво.
Ограничивай потребление зажратых приложений с помощью ulimit или даже cgroup.
Что равносильно деактивации свопа. Система всё равно зависнет.
чем мешает ссд использванию свопа?
По дефолту oomkiller рассчитывает, какое приложение менее приоритетно, чтобы его убить, посему отрабатывает он долго.
proc/sys/vm/oom_kill_allocating_task (since Linux 2.6.24) This enables or disables killing the OOM-triggering task in out-of- memory situations.
If this is set to zero, the OOM-killer will scan through the entire tasklist and select a task based on heuristics to kill. This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed.
If this is set to nonzero, the OOM-killer simply kills the task that triggered the out-of-memory condition. This avoids a possibly expensive tasklist scan.
If /proc/sys/vm/panic_on_oom is nonzero, it takes precedence over whatever value is used in /proc/sys/vm/oom_kill_allocating_task.
Источник
Как предотвратить зависание Linux при нехватке памяти?
Сегодня я (случайно) запускал некоторую программу на своем Linux-боксе, которая быстро использовала много памяти. Моя система застыла, стала невосприимчивой, и поэтому я не смог убить преступника.
Как я могу предотвратить это в будущем? Не может ли он хотя бы сохранить реагирующее ядро или что-то работающее?
5 ответов
Готов поспорить, что система фактически не «замораживалась» (в том смысле, что ядро зависало), а скорее просто не реагировала. Скорее всего, это была просто замена очень сильно, что привело к тому, что интерактивная производительность и пропускная способность системы упали как камень.
Вы могли отключить своп, но это просто изменило проблему из-за низкой производительности на OOM-убитые процессы (и все, что приносит удовольствие), а также снизилась производительность из-за меньшего объема доступного дискового кэша.
В качестве альтернативы вы можете использовать лимиты ресурсов для каждого процесса (обычно называемые rlimit и /или ulimit ), чтобы исключить возможность отдельного процесса, занимающего смехотворный объем памяти и вызывающий замену, но это просто подталкивает вас к занимательной территории процессами, которые умирают в неудобные моменты, потому что они хотели получить немного больше памяти, чем система была готова их предоставить.
Если бы вы знали, что собираетесь делать что-то, что может вызвать массовое использование памяти, вы, вероятно, могли бы написать программу-оболочку, которая сделала бы mlockall() , а затем exec’d вашей оболочки; который сохранит его в памяти и будет самым близким к тому, чтобы «сохранить реагирующее ядро», которое вы, скорее всего, получите (потому что это не то, что процессор перенаправляется, что является проблемой).
Лично я подписываюсь на метод управления «не делай глупых вещей». Если у вас есть root, вы можете наносить всевозможные повреждения системе, и поэтому anything , что вы не знаете, какие вероятные результаты являются рискованным бизнесом.
Как упоминалось выше в комментарии Tronic, можно вызвать OOM-killer (из памяти убийцы) непосредственно комбинацией клавиш SysRq — F .
Ключ SysRq обычно объединяется в клавише PrtSc на клавиатурах.
OOM-killer убивает некоторый процесс (-es), и система снова реагирует.
PS: Это очень помогло мне. Я согласен с мнением, что это самый полезный совет по этой проблеме, если это вызвано Chrome или каким-либо другим программным обеспечением. Но вам нужно иметь в виду, что OOM-killer может убить какой-то действительно важный процесс, тщательно его использовать.
В этой ситуации Windows отображает диалоговое окно, предупреждающее пользователя о закрытии одного или нескольких приложений.
Если вам хочется перекомпилировать ядро, вы можете попробовать патч из раздела EDIT : https://stackoverflow.com/q/52067753/10239615
Он не вытесняет страницы Active(file) во время высокого давления памяти и, таким образом, позволяет OOM-killer запускаться почти мгновенно, потому что ядру больше не нужно тратить минуты на постоянное передислокацию всех исполняемых кодовых страниц каждого процесса, заставляя замороженную ОС.
Это особенно сложно предотвратить. Это связано с тем, что ядро начинает замену. Одно из решений — отключить swap. Когда система исчерпает память, а не начнет замену, ядро убьет некоторые процессы; обычно он подбирает правильный процесс, чтобы убить, но в любом случае лучше убить случайный процесс, чем иметь безответную систему.
Это может быть особенно хорошим решением для серверов, потому что на серверах часто хватает ОЗУ и когда они начинают использовать пространство подкачки, это означает, что все-таки что-то не так. Тем не менее, рабочим столам обычно требуется место подкачки, поэтому я думаю, что нет хорошего решения для настольных компьютеров. Я часто меняю пространство подкачки на серверах, особенно когда есть подозрение на утечку памяти.
Источник
Нехватка оперативной памяти в Linux на рабочем ПК: оптимизация и действия при зависании
На любой операционной системе часто не хватает оперативной памяти. Рассмотрим, как и сэкономить на увеличении аппаратных ресурсов машины с Linux, и продолжить более-менее комфортно пользоваться компьютером с Linux в условиях нехватки памяти.
Типична такая ситуация: есть своп (swap, раздел подкачки), который начинает использоваться при нехватке оперативной памяти, и размещен он на HDD, то есть жестком диске с низкой скоростью чтения информации. В таких ситуациях операционная система начинает тормозить, подвисает курсор мыши, сложно переключиться в соседнюю tty и т.д. Почему? Потому что планировщик ядра Linux не может выполнить запрос на какое-то действие в запущенной программе, пока не получит доступ к ее оперативной памяти, выполнить следующее действие тоже не может, образовывается очередь из запросов на чтение с диска, и система «подвисает» именно потому, что обработка очереди происходит гораздо медленнее, чем этого хочет пользователь.
Если в такой момент запустить htop или uptime , то показатель Load Average (LA) будет очень высоким, несмотря на низкую загруженность ядер процессора. Сочетание высокого Load Average и низкой загрузки процессора говорят о забитой очереди процессора.
Часто в интернете советуют изменить параметр ядра Linux vm.swappiness . Узнать его текущее значение на вашей системе можно так:
Ответ будет 60 почти наверняка. Это значит, что ядро Linux начинает свопить редко используемые страницы оперативной памяти, когда использование свободной оперативной памяти достигает 100%-60%=40%. Часто встречаются рекомендации поставить, например, vm.swappiness=10, чтобы своп не начинал использоваться, пока загрузка ОЗу не достигнет 90%. На самом деле не нужно трогать vm.swappiness, вы не умнее разработчиков ядра Linux, которые не просто так поставили 60 по умолчанию. Почему?
Представьте, что у вас всего 4 ГБ оперативной памяти, из них прямо сейчас занято 3 ГБ, vm.swappiness=10, своп на жестком диске (HDD) занят на 0%, и вы открываете тяжелый сайт в браузере, для чего требуется больше, чем имеющийся свободный 1 ГБ, например, 2 ГБ. Операционная система начинает в экстренном порядке отправлять в своп как минимум 0.5 ГБ (а по факту больше), чтобы можно было выделить браузеру необходимое количество оперативной памяти. Эта процедура становится самой приоритетной задачей, и придется пожертвовать даже движениями курсора мыши, чтобы ее выполнить как можно быстрее. Вы ждете. Проходит 5 минут, и система развисает, потому что окончила процедуру 100% загрузки очереди доступа к медленному жесткому диску, на котором размещена оперативная память (своп). При дефолтном vm.swappiness=60 редко используемые страницы памяти сбрасываются в своп заблаговременно, и резкого зависания на 5-10 минут не происходит.
UPD. В комментарии подсказывают, что это не точное описание работы vm.swappiness.
zram и приоритеты свопов
Рекомендую включить zram — прозрачное сжатие содержимого оперативной памяти. В Ubuntu это автоматизировано, достаточно установить пакет:
sudo apt install zram-config
Здесь и далее для дистрибутивов Rosa, Fedora все то же самое, но вместо zram-config —
Сервис systemd zram-config на Ubuntu будет автоматически добавлен в автозагрузку при установке пакета и запущен при перезагрузке системы. Для запуска вручную:
sudo systemctl start zram-config
sudo systemctl stop zram-config
Удаления из автозапуска:
sudo systemctl disable zram-config
Добавление в автозапуск:
sudo systemctl enable zram-config
При запуске zram-config берет число, равное 50% всего объема оперативной памяти, далее делает по одному виртуальному устройству /dev/zramN, где N начинается с 0, для каждого ядра процессора, а объем каждого /dev/zramN равен 50% всей оперативной памяти, деленному на количество ядер процессора. Так делалается для распараллеливания сжатия содержимого оперативной памяти по ядрам процессора; насколько я знаю, на современных ядрах Linux достаточно одного устройства /dev/zramN, а распараллелится оно само, но меня полностью устраивает искоробочная работа zram-config, и предпочитаю не лезть в нее руками.
Команда swapon -s выведет список всех задействованных свопов с указанием их приоритета. Первым используется тот своп, у которого приоритет выше. Если у вас уже есть дисковый своп и включен zram, то в случае с описанным выше пакетом-автокофигуратором приоритеты из коробки будут правильными. Например, у дискового свопа будет -1, а все /dev/zramN — 5. Таким образом, сначала используется zram, и только потом — диск.
Кстати, zram часто применяется на смартфонах, какую-либо на глаз заметную нагрузку на процессор при дефолтном методе сжатия lz4 он не создает.
Также приоритет свопа можно указать в /etc/fstab . Покажу на примере, как это сделано на моем рабочем компьютере с 6 ГБ ОЗУ.
Опцией монтирования pri=X заданы приоритеты свопов. Если еще включить zram, то картинка будет такой:
В первую очередь будет свопиться в zram, то есть сжиматься внутри оперативной памяти без использования внешнего устройства для свопа, во вторую — использовать небольшой своп на SSD. Почти никогда не будет использоваться 6 ГБ свопа на HDD, однако они понадобятся, если я захочу отправить компьютер в спящий режим в условиях большой загрузки оперативной памяти. (На самом деле у меня отключен zram).
На офисных ПК с 4 ГБ ОЗУ (Xubuntu 16.04, 17.10) всегда ставлю пакет zram-config . Chromium, по наблюдениям, на глаз, очень хорошо сжимается в оперативной памяти, в результате чего zram позволяет сделать работу намного более комфортной без модернизации железа.
Быстро вырубить программу, перегружающую ОЗУ. Запас ОЗУ для SSH
Бывает такое, что даже при vm.swappiness=60 какому-то черту, как правило, браузеру, требуется очень много оперативной памяти, и система подвисает. Решается очень просто: сочетание клавиш Alt+SysRq(PrintScreen)+F заставляет oom_killer принудительно включиться и вырубить процесс, который на момент вызова занимает больше всего памяти. Строго 1 процесс на 1 вызов, и строго обязательно что-то будет убито. Если много раз подряд нажмете, то, скорее всего, перезапустится графическая сессия. Событие убиения процесса отражается в dmesg красным цветом.
Однако эта штука, называющаяся Magic SysRq, из коробки отключена в большинстве дистрибутивов, потому что непривилегированный пользователь может убить абсолютно любой процесс. За это отчечает параметр ядра kernel.sysrq , узнать его текущее значение можно так:
Для работы Alt+SysRq+F нужно kernel.sysrq=1. Для этого отредатируем параметры ядра, расположенные в файлах /etc/sysctl.conf (обычно симлинк на /etc/sysctl.d/99-sysctl.conf) и /etc/sysctl.d/*.conf. Лучше всего создать отдельный файл:
sudo nano /etc/sysctl.d/99-dumalogiya.conf
Нажмем Ctrl+O, Enter для сохранения.
В случае с браузером Chromium Alt+SysRq(PrintScreen)+F будет вырубать по одной вкладке, не закрывая сам браузер, что очень удобно.
Сочетания клавиш Magic SysRq перехватываются напрямую ядром Linux, поэтому работают даже когда из-за очереди процессора подвисает X-сервер.
Источник
