Убунтята, не проходите мимо: le9 patch добавлен в linux-xanmod и ваш OOM killer будет вылечен

На ядре NT, если я правильно понимаю, ситуация обстоит чуть лучше, потому что контроль рабочего набора осуществляется не глобально, а per process.

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

В линукс же алгоритм откачки страниц всегда выполняется глобально.

ШТО

Ничего. Сегодня мой юмор что-то вообще никто на этом сайте не понимает.

Какое это имеет отношение к тому, что ты выбрал меленную подкачку вместо быстрой?

А какое отношение скорость подкачки имеет к процессам, которые в ней не нуждаются?

скорость устройства можно замерить

А какое отношение скорость подкачки имеет к процессам, которые в ней не нуждаются?

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

Что касается zram vs HDD: своппинг на zram к тому же многопоточен.

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

Я об этом и говорю, что система не разбирает, кто сколько памяти потребляет. А нужно — разбирать.

А нужно — разбирать.

На этот случай есть memavaild:

tail /dev/zero, swap on HDD, memavaild, no freezes https://www.youtube.com/watch?v=DsXEWvq60Rw

23.05.21 20:40:22

вы задрали некропостить

Здесь всё актуально.

Потому что это создание надуманной проблемы, а потом героическое её решение.

Плох алгоритм? Плоха идея?

Всё плохо. Отключите своп и радуйтесь.

не бугурть, тред актуален еще, вскрыта свежая тема

создание надуманной проблемы

проблема существует независимо от нас, существует объективно

героическое её решение

не героическое, а лёгкое решение путем легкой правки патча le9

Отключите своп и радуйтесь

мне и со свопом радостно, зачем его отключать?

Будто люди просто так начинают скачки на sysctl.
Эти худшие практики возникают не на пустом месте.

лёгкое решение

…путём рандомного принудительного mlock()’а?

Потому что страшно и непонятно, не?

Эти худшие практики возникают не на пустом месте.

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

Что непонятно? Где что непонятно?

…путём рандомного принудительного mlock()’а?

Так там не mlock. Просто патч ПОЗВОЛЯЕТ не вытеснять анонимку, если ее объем начнет угрожать отзывчивости. Если анонимки остается единицы и десятки МБ - отзывчивость падает, хотя и не так сильно, как в случае с файл кэшем. И не РАНДОМНОГО, а на наиболее активную анонимку.

BTW, резерв анонимки позволяет предотвращать панику с le9 и i915.

Да нет этих лучших практик.

Лучшими их считаешь ты, потому что тебе помогло в твоих конкретных случаях и ты не сталкивался со случаями когда не помогает, вот и всё.
Обыкновенная неспособность понять и принять опыт другого человека.

Такие параметры:

Двое суток использую xanmod ядро с этими параметрами и комбинированным zram/hdd свопом.

Поведение системы под swap-нагрузкой заметно более плавное, чем на ванилле.

Память в основном неконтроллируемо жрет firefox и еще предположительно что-то течет ресурсами, раздувая память в Xorg.

Да нет этих лучших практик.

Есть.

и да, заголовок 4.2
Линуксы зависают при нехватке памяти:

и при хватке тоже!

Почему бы все эти ограничения снизу не сделать через cgroups?

Каким образом i915 к анонимной памяти?

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

И как это поможет при разрастании zram?

zram вообще каким типом памяти считается?

zram вообще каким типом памяти считается?

Память модуля zram не относится к спискам LRU и не отображается в /proc/meminfo. Тёмная ядерная материя, так сказать.

И как это поможет при разрастании zram?

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

• предотвращение бага https://github.com/hakavlad/le9-patch/issues/6 - он как раз проявляется при вытеснении практически всей анонимки в своп. Сохранение некоторого объема анонимки до вызова киллера может предотвращать баг;
• меньше падает отзывчивость перед ООМ в этих случаях - киллер вызывается до вытеснения рабочего набора в своп. В стандартном le9 защищается только файловая часть рабочего набора. Дополнительная защита анонимной части рабочего набора решает две проблемы.

Каким образом i915 к анонимной памяти?

См ответ выше. Баг https://github.com/hakavlad/le9-patch/issues/6 проявляется при вытеснении всей анонимки в своп.

Почему бы все эти ограничения снизу не сделать через cgroups?

Это слишком сложно. Это ж в каждом слайсе memory.min прописывать. Это неудобно. Плюс это не работает без unified cgroup hierarchy. И ты уверен, что memory.min защищает только анонимку?

Способ через патч проверен и работает отлично.

Просто реальный пример из жизни.

2 гига памяти, 6 гиг своп на zram. Открываем браузеры, открываем много вкладок, запускаем supertuxkart, продолжает открывать вкладки. zram разрастается, размер списков анонимной памяти уменьшается. При околонулевом размере анонимки происходит OOM. С драйвером i915 ко всему прочему проявляется описанный выше баг - гуй замирает, переходим в соседнюю виртуальную консоль и видим в журнале BUG. Резервация пары сотен МБ анонимки может предотвращать это. ООМ проиходит немного раньше, но зато без BUG и до вытеснения анонимной части рабочего набора в своп.

это создание надуманной проблемы

https://github.com/hakavlad/le9-patch/issues/6 - это надуманная проблема?

предотвращать панику с le9 и i915

Не панику, а всего лишь Oops

Поставил zswap на треть ОЗУ, послежу за разницей.

Удалось загнать систему в длительный лаг при помощи запуска штук восьми:

seq -sxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1 100000000 | tail &

Если только две запускать, они умирают, похоже, намного раньше, чем начинается выгрузка в реальный своп. Неужели он так эффективно жмет?…

Если только две запускать, они умирают, похоже, намного раньше

выстави overcommit=1. Они умирают от невозможности выделить виртуальную память скорее всего.

с overcommit=1 1 процесс ушел с своп на 18ГБ и до сих пор не завершился.

~$ oom-sort
oom_score oom_score_adj  UID   PID Name            VmRSS   VmSwap   cmdline
--------- ------------- ---- ----- --------------- ------- -------- -------
      985             0 1000 19199 tail             6766 M  16610 M tail

Удалось загнать систему в длительный лаг

у меня длительного лага не бывает с такими мелочами. Если только собирать ядрос более 500 потоками.

Или если я пользователь, то не могу предположить, что например, сервер в конторе может и скувыркнуться под обилием виртуалок?

Если у тебя виртуалки полезли в своп, это плохо, это заметно, и ты добавишь память. Но система не упадёт, так как ты же не пожалел на своп гигов 15-20? Или пожалел? Ну тогда ССЗБ.

Держи синтетику: https://github.com/hakavlad/nohang-extra/blob/master/mem-load/mem-load

Что она делает? Складывает случайные числа в список.

Что можно настраивать?

• сколько миллионов чисел поместить в список;
• сколько раз повторить процедуру - после наполнения списка можно перезаписать элементы списка новыми числами;
• сколько процессов запустить.

Пример:

./mem-load 999 0 8

В этом примере 8 процессов наполнят свою память списками по 999000000 случайных чисел.

Демо с этой же командой: https://www.youtube.com/watch?v=1uhcZwuvXLI

Запускаем этот cтресс, играем с supertux.

Конфиг vm:

vm.anon_min_kbytes=250000
vm.clean_min_kbytes=250000

Mem_total=9.6G, zram mem_used_total=8.7G (пиковое потребление памяти модулем zram), swap total = 38.2G.

В фоне работает nohang в режиме только мониторинга kmsg - уведомляет об OOM.

Степень сжатия получается примерно 2.5:1.

Есть ли на видео длительные лаги?

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

Есть для Ubuntu 12.04?

Есть. Можешь ставить новое ядро в старую убунту. Репа в оп-посте.

Интересная мысль. То есть, компилировать в целевой системе не надо?

готовые сборки https://xanmod.org/#install_via_terminal - с патчем. Не забудь покрутить ручки после установки.

Какие ручки?

Я скорее всего пересоберу из исходников под целевую систему.

Mem_total=9.6G, zram mem_used_total=8.7G (пиковое потребление памяти модулем zram)

Опечатка же. mem_used_max=8.7G, а не mem_used_total. mem_used_total постоянно меняется.

Однохренственно. Вот лог с overcommit = 0, но с 1 то же самое:

июл 10 15:46:42 aquila kernel: Mem-Info:
июл 10 15:46:42 aquila kernel: active_anon:218784 inactive_anon:1207783 isolated_anon:32
                                   active_file:20351 inactive_file:16304 isolated_file:0
                                   unevictable:2470 dirty:19 writeback:0
                                   slab_reclaimable:13741 slab_unreclaimable:58796
                                   mapped:31742 shmem:146438 pagetables:10826 bounce:0
                                   free:25575 free_pcp:367 free_cma:0

<SKIP>

июл 10 15:46:42 aquila kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
июл 10 15:46:42 aquila kernel: 184602 total pagecache pages
июл 10 15:46:42 aquila kernel: 1479 pages in swap cache
июл 10 15:46:42 aquila kernel: Swap cache stats: add 32913749, delete 32914465, find 454223/986500
июл 10 15:46:42 aquila kernel: Free swap  = 0kB
июл 10 15:46:42 aquila kernel: Total swap = 8388604kB
июл 10 15:46:42 aquila kernel: 2075020 pages RAM
июл 10 15:46:42 aquila kernel: 0 pages HighMem/MovableOnly
июл 10 15:46:42 aquila kernel: 60857 pages reserved
июл 10 15:46:42 aquila kernel: 0 pages hwpoisoned

<SKIP>

июл 10 15:46:42 aquila kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=lightdm.service,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-2.scope,task=tail,pid=23910,uid=1000
июл 10 15:46:42 aquila kernel: Out of memory: Killed process 23910 (tail) total-vm:10050200kB, anon-rss:4844544kB, file-rss:1228kB, shmem-rss:0kB, UID:1000 pgtables:19704kB oom_score_adj:0

Какие ручки?

vm.clean_low_kbytes, vm.clean_min_kbytes

описание ручек см там https://github.com/hakavlad/le9-patch/blob/main/le9db_patches/le9db0-5.10.patch

То есть, если у меня червёртый пень прескотина с 1 Гб памяти, мне что ставить надо?

Если используешь только zram, достаточно выставить vm.clean_low_kbytes (там по умолчанию уже выставлено).

Если используешь реальный своп, то лучше vm.clean_min_kbytes тоже подкрутить.

Мне кажется, если у тебя 4-й пень, то лучше на помойку его отнести, и принести оттуда хотя бы Core 2 Duo.