Когда линь перестанет виснуть при исчерпании памяти? (2022)

Покупай больше, ещё больше оперативы. Проблему с памятью в Linux не могут решить ни команды дистрибутивов, ни пользователи этого сайта. Я себе поставил 256 GB, пока, как правило, хватает.

Я себе поставил 256 GB, пока, как правило, хватает

LOL. Учитывая тенденции софтостроения, я боюсь, мне тоже придется 256 ставить. Но это абсурд, потому что реально мне столько не нужно.

Кстати, аналогичный страдалец без свопа: Эффективная борьба с зависаниями по исчерпании памяти? (2019)

Я эту проблему решил включением zram. С тех пор ни разу не зависло больше.

Ну ты просто немножко оттянул момент окончания памяти, пытаясь пожать ей. Рано или поздно, память закончится даже с учётом zram и ты влетишь в ту же самую ошибку.

А вот прикинь, не кончается. Я хз как. Когда заполняется процентов этак 85-90, начиаются весьма сильные тормоза - 12309, но не зависает никогда окончательно.

Вот реально, с момента подключения года с 2018 ни разу больше не было зависаний. А до этого регулярно. Приходилось внимательно следить за тем, что включаю.

Вангую vm.dirty блочит, но почему оно блочит сразу все, хз
Можно попробовать ограничить для приложения скорость записи, можно даже динамически или приоритеты, но как хз

Отхожу от лэптопа с 4-мя ГБ оперативки и запущенным браузером с множеством вкладок (но с заблокированным показом видео на страничках). Прихожу - а там гул вентилятора, и нет реакции даже на NumLock. Ну, есть, если подождать с минуту. Но иногда бывает, возвращаюсь - браузер убит. В итоге разрешил в Debian вызов OOM по alt+sysrq+f - больше не надо терять рабочую сессию. Не ожидал, чтобы стандартные настройки (да и соответствующая архитектура) были настолько абсурдны.

Попытки исправить ситуацию в mainline от hakavlad: Убунтята, не проходите мимо: le9 patch добавлен в linux-xanmod и ваш OOM killer будет вылечен.

Гугл продвигает: Тестируем Linux 5.12—5.17 с патчем Multigenerational LRU Framework.

В итоге разрешил в Debian вызов OOM по alt+sysrq+f - больше не надо терять рабочую сессию

Ты мой Бох. Я не знал, что такие кнопалки в лине есть. Систему я ребутал через SysRq, но oom-killer здесь самое оно.

Тру красноглазое решение - выпиливание всего жирного софта и юзать консольные приложения. :-)

Не у всех они есть

Можно решить легче: написать скриптик, который при достижении 95% заполненнности ОЗУ будет отрубать самую жрущую программу.

У меня на 8гб на ноуте со встроенной видяхой по 4 клиента вовки можно, плюс браузер. Тормозить будет, но не зависнет. А можно несколько сотен вкладок в браузере. Недавно было 812…

Zram творит чудеса.

И если ты отходишь и за время отсутствия зависает, глянь что у тебя течет. Это ненормально.

Ты только что изобрел oom-killer.

Ты только что изобрел oom-killer

Неа, earlyoom. По итогу я его себе и поставил. Oom-killer по моим ощущениям вообще ничего не убивает. ХЗ из-за чего так и в какой момент разрабы линя пролюбили идею в фундаменте.

У меня на 8гб на ноуте со встроенной видяхой по 4 клиента вовки можно, плюс браузер. Тормозить будет, но не зависнет. А можно несколько сотен вкладок в браузере. Недавно было 812

Тормоза недопустимы. Если система не может втиснуться в тот объем оперативы, который я ей указал (не важно, со свопом или без), то она должна грохать приложухи. Даже винда так делает, хотя формально там нет oom-убийц.

Когда ты включишь физический своп. В особо тяжёлых случаях ещё надо включить zswap и не мешать ему работать и отсечь systemd от управления памятью через cgrops.

А вообще можешь обрисовать задачу в которой ты смог подвеситься?

Я считаю, что на этот вопрос может ответить только толстенная книга с названием «как настраивать работу с памятью в Linux». Объём материала, который надо знать слишком большой, чтобы его можно было изложить на форуме.

https://docs.kernel.org/admin-guide/mm/index.html (и это только про ядро. А ещё ведь есть пользовательский софт.)

а чего там у тебя с памятью? у меня 2 гига - хватает, swap на всякий случай конечно есть, но он никогда не используется.

А на что сейчас может хватать 2гб озу, если один клиент вовки 2,8 жрет?

Никогда.

на что сейчас может хватать 2гб озу

на все если не крутить винду в виртуалке

клиент вовки

не понимаю что это такое

не понимаю что это такое

Счастливый человек :)

vm.vfs_cache_pressure = 20

И не должно было. Так может стать только хуже. cast post-factum. Чтобы стало лучше, надо отрубить к чертям дисковый свап, включить zram, увеличить swappiness и включить юзерспейсный киллер. ТОгда система ведет себя лучше. Если не лень, можно поиграться с патчем от hakavlad

Через cgroups блокируешь софту от своего пользователя есть более 95% всей оперативной памяти ОС. Всё, ОС никогда не зависнет. Правда ПО будет падать, но ОС нет.

Когда уберут overcommit и научатся писать приложения, обрабатывающие нехватку памяти.

В том же Windows overcommit в целом не применяется.

на этот вопрос может ответить только толстенная книга с названием «как настраивать работу с памятью в Linux»

Там еще должна была быть первая глава под названием «за каким хером мы сделали дефолт принципиально неработоспособным и не чешемся».

можно было конечно нагуглить, но хотелось бы услышать мнение местных экспердов?

mkdir /sys/fs/cgroup/softina/
echo 6G > /sys/fs/cgroup/softina/memory.high
echo $$ > /sys/fs/cgroup/softina/cgroup.procs
./softina

+1. Создаёшь контролгруппу, назначаешь ей лимит по памяти и добавляешь в неё нужный софт.

Не обязательно. Достаточно разобраться с swapiness, zram и earlyoom. Я гарантирую это.

Кстати, а как это работает в Haiku?

Зависит от того, как собрать ядро.

zRAM с подобным мусором не справляется?

Обычно без overcommit. Если кончилась память, то malloc вернёт NULL. OOM killer отсутствует.

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

упдате оказывается выше уже предложили, кажется это вполне рабочий вариант

8 гб оперативы. Было запущено куча барахла, 2 гб свопа или около того. Всё норм пахало. Manjaro KDE, Linux 5.10.102

Когда линь перестанет виснуть при исчерпании памяти? (2022)

Когда это понадобится бизнесу. Пока что всем хватает велосипедов и недорешений.

у меня 2 гига - хватает, swap на всякий случай конечно есть, но он никогда не используется.

+1, на расбери3 с 1гб всего один раз попал на зависания, потенциально по причине упирания в озу (но и то не факт). Притом Висла даже не ось а отдельный Ява процесс (вм)

World of Warcraft, игра для винды, замечательно работающая под wine. :)

не играю и wine не пользуюсь, ставил конечно пару раз - посмотреть, мне не подходит - виндовый софт не видит флешки

Используй solaris, например...

Идея в фундаменте =- не писать программы, жрущие память как не в себя.

Чтобы корова давала больше молока, её надо лучше кормить. (Вариант с меньше кормить и больше доить неработоспособен)

А Linux чтобы лучше работал - память вставлять.

Нет, это путь в никуда. Надо экономить ресурсы.

Когда линь перестанет виснуть при исчерпании памяти?

Хуже всего то, что при отсутствии свопа данный сценарий наступает очень резко, лавиннобразно

Правильно заданный вопрос – половина ответа. Использовать swap на реальном накопителе.

Обычно без overcommit. Если кончилась память, то malloc вернёт NULL. OOM killer отсутствует

Да, так делает и винда. Я считаю оптимистичное выделение памяти никсами фундаментально провальным. Причем, с этим ничего не сделать, потому что есть fork, который делает copy-on-write и под него нельзя резервировать память.

Причем, с этим ничего не сделать, потому что есть fork, который делает copy-on-write и под него нельзя резервировать память.

Есть posix_spawn, который создаёт процесс с нуля.

Есть posix_spawn, который создаёт процесс с нуля

Есть. Только fork ты пользовать не запретишь. Не устаю восхищаться тому, насколько грамотно было продумано ядро винды.

Не устаю восхищаться тому, насколько грамотно было продумано ядро винды.

До первого апреля ещё далеко.