Ядро Linux не может мягко обрабатывать ситуации с нехваткой памяти. Как побороть?

На этой неделе просмотрел довольно много материала по этому вопросу. Сделал предельно краткую выборку.

1. На нашем форуме zRam + swap (пять лет назад).
2. Ядро Linux не может мягко обрабатывать ситуации с нехваткой памяти (~ год назад).
3. Значение swappiness при использвании ZRAM (март - октябрь 2020 года).

И самый свежачок. Вишенка на торте - ветка, заявляющая о костыльном, НО -- решении этой проблемы ядра. Обсуждение открыто 3 октября 2020 года. Все три демона, предлагаемые для комплексного решения проблемы, уже находятся в репах Fedora. У нас они размещены в AUR.
Кстати, пишут в Linux 5.8 появилась возможность выкручивать vm.swappiness до 200.

ВНИМАНИЕ!
Цель создания топика: "коллективным разумом" форумян сформировать настройки ядра в текущем моменте времени. Возможно для различных объёмов RAM (4 Гб, 6 Гб, 8 Гб, 16 Гб и т.п.). Настройки которые с использованием zRAM, swap, различных демонов позволят избежать озвученной в заголовке проблемы.

Убедительная просьба прежде чем высказываться хотя бы внимательно прочитать предложенное (если не знакомы). А наиболее лучший вариант поделиться опытом практического применения собственных настроек. Или проведённых экспериментов на основании предложенных выше вариантов. Торопиться не надо)
Если вопрос поднятый в ветке заинтересует коллег, здесь будут публиковаться результаты обсуждения и рекомендации по настройке.

Особого интереса у сообщества вопрос не вызвал.

Рекомендация коллеги vasek.

Вот здесь поделился своим опытом.
Самое большое значение потребления памяти видел один раз - это 15% из 32-х гигабайт, уже не помню что это было. Активный свап видел однажды (где то есть тема на форуме в /dev/null), но это была Центось, и то после неких экспериментов с режимом работы ядра.
In Tux We Trust
redix
Самое большое значение потребления памяти видел один раз - это 15% из 32-х гигабайт
Будем считать это оптимистичным началом обсуждения темы -- опыт показывает, что любую проблему можно решить. Как вариант -- кардинальным образом )))
vall
Как вариант – кардинальным образом )))
Это вы про объем? )))
In Tux We Trust
Была уже похожая тема
У самого earlyoom стоит, но исчерпание памяти у меня очень редкий случай
redix
Это вы про объем? )))
Про объём, конечно же)
Ветка, собственно говоря, предлагает рассмотреть альтернативные решения. Доступные на сегодняшний день.

У меня после чтения много чего в сети возникло стойкое убеждение, что тема довольно активно развивается линукс сообществом. И то что, - как пример, - предлагалось коллегой red на данном форуме и было новшеством некоторое время назад, требует обновления. И даже переосмысления, с учётом появления новых инструментов и возможностей (в ядре и т.д., и т.п.).

И, судя по некоторым отзывам, эти новые инструменты достаточно эффективны.
vs220
Была уже похожая тема
Пропустил. Там даже автор этих самых демонов (hakavlad) оказывается предлагал задавать вопросы. Если топик заинтересует форумян, возможно он и здесь поможет разобраться. Раскроет тему более широко.

Поскольку тюнинг memavaild и prelockd практически не задокументирован. Да и в nohang настроек немало.

vs220
У самого earlyoom стоит
У меня в моменте тоже. Вот и первый вопрос -- в чём преимущество его инструментов?
vs220
earlyoom стоит
Много чего перепробовал и в конце остановился на следующем
- удалил все приблуды, имеющие отношение к памяти, точнее к ее ограничению (nohang и пр.) и сжатию (типа zram и др.)
- отключил swap (точнее закоментировал в fstab)
- активировал earlyoom

Проблем с памятью не имею - ни зависаний ни фризов при нагрузке на память (имею всего оперативы 6G), система отзывчива ...
Как пример, запустил скрипт вывода используемой памяти каждые 5 с и запускаю мощную карту - одну и ту жу около 10 раз - зависаний нет.
Вывод используемой памяти
~/mem.sh
502
509
1751
2280
2453
3718
4408
4567
4379
4647
3816
3817
4683
3942
4931
4386
4738
4186
4501
4565
3814
473
473
473
474
Деактивирую earlyoom и делаю то же самое - при 4 открытии карты система встала колом, ждал около 5 мин.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Много чего перепробовал и в конце остановился на следующем
- удалил все приблуды, имеющие отношение к памяти, точнее к ее ограничению (nohang и пр.) и сжатию (типа zram и др.)
- отключил swap
- активировал earlyoom

- вопрос ветки возник именно с приблуд: надо ли мудрить с zram и/или zswap
- своп-файл 3 Гб оставил в 1/2 памяти
- активировал earlyoom с параметрами в конфиге
EARLYOOM_ARGS="-m 15 -s 85 -r 60 -n --avoid '(^|/)(init|systemd|Xorg|sshd)$' --prefer '(^|/)(telegram-desktop)$'"

В общем-то система колом не встаёт, как могла раньше. Может периодически фризится и пошла далее. Или в кедах падает kwin, тогда приходится alt+ctrl+f2. Затем возвращаться и WM восстанавливается со сбросом openGL. И это как-то рандомно. То нормально OOM killer срабатывает; то как рассказал выше.
 
Зарегистрироваться или войдите чтобы оставить сообщение.