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

Ваниль и не должна использоваться в норме. Ваниль - это примерный усредненный образец ядра

Как же тогда огромное число людей пользуются Windows и Mac OS с ванильным ядром? Там патчить ядро не принято, вместо этого принято делать динамически-загружаемые модули ядра.

Вся эта практика с патчингом ядра и других компонентов авторами дистрибутивов глубоко ущербна и не вызывает доверия.

зато в вантузе принято патчить память процессов во время исполнения. всё через жопу у проприетарастов

sysctl vm.panic_on_oom=1

Как эта опция работает? Что подразумевается под oom? Сбрасываются ли файловые кеши при OOM (полагаю, что да, но всё же)? Производится ли безопасное размонтирование файловых систем?

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

Но зачем?

Продолжать работу после того, как oom killer убил рандомное приложение смысла просто нет. Система уже априори нестабильна. Простой пример: oom killer убивает ntp-демона, часы у системы разошлись с глобальными, база данных стала неконсистентна, пару дней пытаемся восстановить из бэкапа.

Пример поприкольней. HP драйвер для рейда запускает кучу процессор вида hpvsa/1 и тд. killer убивает такой процесс, рейд превращается в шляпу, бизнес подаёт на банкротство.

Как эта опция работает?

См. https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/sysctl/vm.rst#panic_on_oom

Что подразумевается под oom?

См. у Гормана 13.2 Determining OOM Status https://www.kernel.org/doc/gorman/html/understand/understand016.html (хотя инфа там немножко устарела)

Сбрасываются ли файловые кеши при OOM

Обычно да - ООМ происходит после обнуления кэшей и свободной памяти - когда нет памяти, за счет которой можно удовлетворить новый запрос.

Производится ли безопасное размонтирование файловых систем?

Нет. Просто паника.

oom killer убил рандомное приложение

киллер убивает не рандомное приложение, а процесс с наибольшим oom_score (если vm.oom_kill_allocating_task=0), This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed. - https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/sysctl/vm.rst#oom_kill_allocating_task

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

ростой пример: oom killer убивает ntp-демона, часы у системы разошлись с глобальными

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

Ядро с данным патчем и стандартными настройками (512 МБ clean_low_kbytes, 0 clean_min_kbytes) позволяет умеренно комфортно использовать:

• Firefox с 37 активными вкладками (все данные в RAM, без выгрузки, всё честно)
• Discord
• Skype
• LibreOffice с открытым документом
• Два PDF-файла (размером 14 и 47 мегабайт)

… на железе 2007 года, с Core2Duo E4600, 2 ГБ оперативной памяти DDR2@667 в одноканале и HDD такого же года! В zram при этом было под 3 ГБ данных: в 1.5 раза больше, чем оперативки физически (сжатие примерно в 3 раза).

Windows 10 на этом компьютере еле-еле запускается, не то, что работает. Нужно отметить, что и линукс без патча le9 еле шевелится, и swappiness не помогает: даже если его выставить в 200, файловый кеш всё равно активно вымещается.

Без патча при заполнении RAM всё начинает тормозить, прежде всего это выражается в значительных задержках (десятки секунд-несколько минут) при переключении приложений из-за низкой скорости чтения с HDD. С xanmod же можно переключиться из браузера в Discord так, будто ваш компьютер вобрал в себя всю свободную оперативку мира. Компьютер ни разу не приблизился к состоянию «зависания» (thrashing) — система временами замедлялась, но была полностью отзывчива.

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

https://files.catbox.moe/90ag3c.mp4

P.S. этот компьютер стоит дешевле, чем один модуль оперативной памяти DDR4 4 GB в розничной продаже.

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

Это не софизм: я купил этот компьютер за 1700 рублей на прошлой неделе, как раз для тестирования работоспособности современных ОС на слабом старом железе, и он обошелся на 200 рублей дешевле оперативной памяти DDR4, которая тоже была куплена на прошлой неделе.

Очень информативный отзыв. Спасибо!

А если еще FOX Desktop (Ловите наркомана!) допилить под такие машины, будет полный винегрет. %)

этот компьютер всё ещё никаким образом не заменяет одного модуля памяти на 4гб и не эквивалентен тому по возможностям, твоё сравнение их цен - глупость

Этот компьютер в сборе стоит дешевле одного компонента современного компьютера, а работает с теми же операционными системами и программами. Чем такое сравнение хуже, чем сравнение со стоимостью чашки кофе?

В любом случае, это оффтоп.

а работает

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

Этот компьютер в сборе стоит дешевле

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

а вот покупка модуля памяти позволит выполнять больший круг задач

а вот покупка модуля памяти позволит выполнять больший круг задач

Только нужно комп сначала купить. :3

ну так в итоге приходим к тому, что к его хламу таки приходится докупать этот злосчастный 4гб модуль, а не сравнивать их цены)))

Скачать бесплатно

А платно где?

К его хламу скорее всего 4 ГБ модуль никак не приделать.

Тут нужно купить б/у платформу хотя бы тысяч за 10, чтобы она не была совсем уж дровами.

Ну а запуск системы в 2-3 гигах с большой нагрузкой на память — это интересный стресс-тест сам по себе.

Сижу на убунте:

OS: Ubuntu 20.04 focal
Kernel: x86_64 Linux 5.4.0-77-generic
DE: GNOME 3.36.5
Uptime: 2d 55m
RAM: 7941MiB / 11898MiB

случайного файлового кеша

Ну таки не случнайный, а наиболее используемый, ибо LRU - вытесняется кэш неиспользуемых файлов, а кэш наиболее используемых - защищается.

https://liberapay.com/xanmod/donate

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

Вот и мейнтейнеры ядра не верят и не понимают. Например, Michal Hocko:

I am afraid there is nothing like that available and I would even argue
it doesn't make much sense either.

– https://lore.kernel.org/lkml/20190808163228.GE18351@dhcp22.suse.cz/ - хотя ndrw ровно это и предлагал:

Would it be possible to reserve a fixed (configurable) amount of RAM for caches, and trigger OOM killer earlier, before most UI code is evicted from memory? In my use case, I am happy sacrificing e.g. 0.5GB and kill runaway tasks _before_ the system freezes. Potentially OOM killer would also work better in such conditions.

– и был совершенно прав! - https://lore.kernel.org/lkml/806F5696-A8D6-481D-A82F-49DEC1F2B035@redhazel.co.uk/

ребутая пк когда зависает гном из-за мазилы

Что мешает использовать лучшие практики вместо ребута?

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

Накатил xanmod на Арч.

Есть своп в zram и своп на диск. В таком конфиге работать будет?

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

vm.dirty_bytes = 8000000
vm.dirty_background_bytes = 4000000

vm.swappiness = 50

vm.clean_low_kbytes = 500000
vm.clean_min_kbytes = 150000

$ swapon
NAME       TYPE        SIZE   USED  PRIO
/dev/dm-2  partition     8G   2,1G    -2
/dev/zram0 partition 655,6M   529M 32767
/dev/zram1 partition 655,6M 528,7M 32767
/dev/zram2 partition 655,6M 529,8M 32767
/dev/zram3 partition 655,6M 529,3M 32767

Что еще докрутить?

shatsky еще в 2017 здесь все понял

ЧСХ, кроме него никто даже приблизительно не понял, о чем речь. Уровень компьютерной неграмотности у местной тусовки зашкаливает.

le9’s file mappings under memory pressure protection.

Google’s Multigenerational LRU Framework [5.13] [5.12].

Они же несовместимые, нет?

Они же несовместимые, нет?

le9 and mgLRU can coexist.

le9 works only with classic LRU. Enabling mgLRU disables le9 effects.

https://forum.xanmod.org/thread-4102-post-7599.html#pid7599

Могут существовать в одном ядре. Но защита файлов не работает при включении мультиген LRU.

le9 делает свое дело в ф-ции get_scan_count(). C mg-LRU используются другие, новые ф-ции.

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

Что еще докрутить?

dirty можно в 10 раз увеличить.

swappiness можно в 2-3 раза увеличить.

с clean играй сам как хочешь. Это еще тема для опытов.

А вообще надо начинать с показа MemTotal. Какой у тебя диск - HDD, SSD?

своп в zram и своп на диск

Как раз таки сомнительное сочетание из-за инверсии LRU (где-то мы эту тему уже вскрывали). Если уж хочешь своп на диске, то и выбирай zswap.

Если хочешь zram, то и используй только zram.

Они и 12309 не вполне понимают.
«А как мы знаем», если не можешь чего-то понять — то этого нетъ.

12309 в том виде, в котором был раньше, исправлен в 4.10.

В каком виде он был раньше?

Раздувающийся кэш грязных файловых страниц блокировал своппинг - при копировании и при утечке памяти одновременно, например. Сейчас для решения проблемы достаточно ограничивать dirty.

В каком виде проблема существует сейчас? По умолчанию грязные страницы могут занимать до 20% доступной памяти - и вытеснять кэш чистых файловых страниц вместе с кэшем разделяемых библиотек.

стандартными настройками (512 МБ clean_low_kbytes

Там же вроде 150000 https://github.com/xanmod/linux/blob/5.13.1-xanmod1/mm/Kconfig#L127

config CLEAN_LOW_KBYTES
	int "Default value for vm.clean_low_kbytes"
	depends on SYSCTL
	default "150000"

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

Простейшая альтернатива - https://en.wikipedia.org/wiki/Magic_SysRq_key

Alt+SysRq+F - вызов киллера
Alt+SysRq+K - убийство текущей сессии
Alt+SysRq+REISUB - корректная перезагрузка

Из других методов - своп на zram с высоким swappiness и юзерспейсные киллеры (earlyoom, nohang).

Ты не сталкивался с этой проблемой по-настоящему, когда вся эта мастурбация вприсядку не помогает и думаешь, что тут никто не пробовал всё это (доступ к гуглу-то только у тебя).

И 12309 «исправлен» и блокирование самбы при отвале cifs-шары и прочие прелести реального использования линукса на десктопе на самых разных машинах и конфигурациях.

Всё исправлено, человек просто не знал про твои сисрески, эрлиом и нохенг и написал патчи от нечего делать. А ты дартаньян конечно же. (нет)

Тут смешно

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1833281

I am experiencing this bug on a stock Dell Inspiron 5000 (5482) with 8 GB RAM and the factory SSD. It is completely debilitating. Having 1-2 completely unpredictable, 30-minute-plus, hard freezes per day is a showstopper. I can’t trust this environment for professional work, or even to take notes in gedit during a phone call. I’ve been an Ubuntu user and advocate at work and home for 10+ years, but I guess I have to quit :( Fedora 33 does not suffer from this bug, so I’m using that.

Fedora 33 does not suffer from this bug

У Fedora 33 - zram, earlyoom и uresourced. Как видишь, проблема решаема. Ubuntu проблему не решает никак - это позор UBUNTU с 2007 - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/159356

Более того:

Unbelievable!
I have no idea why my system with 32GB of memory is still haunted by this dumb issue.
The ssh got completely unresponsive, even with a physical monitor and keyboard attached to the system, when this happens and the only solution to get back control is a hard reset.
Man.. if anyone from upstream cares about this issue at least give user a prompt to kill the problematic process manually.
Rendering the full system unresponsive like this is unacceptable.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/159356/comments/115

Ты не сталкивался с этой проблемой по-настоящему

я воспроизводил проблему синтетикой

вся эта мастурбация вприсядку не помогает

помогает 100%

блокирование самбы при отвале cifs-шары

Это другое. О чем речь? Где репорт?

человек просто не знал про твои сисрески, эрлиом и нохенг

все так: дистроделы не применяют лучшие практики, а юзеры страдают

А ты дартаньян конечно же

Да.

но ты же рассказывал, что видео встройка интола или ещё какое-то там говно зависает

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

Какой человек? Какие патчи?

Больше способов обработки нехватки памяти богу обработки нехватки памяти! Проблему можно решать с разных сторон, и патчи прочему тюнингу не помеха.

Не ты. Сссыл-очку плиз.

А вообще надо начинать с показа MemTotal. Какой у тебя диск - HDD, SSD?

Оба. Корень на SSD. Своп на HDD. Рабочие данные и на HDD, и на SSD.

ОЗУ 8 ГБ.

I have no idea why my system with 32GB of memory is still haunted by this dumb issue.

Лол. http://www.lorquotes.ru/view-quote.php?id=5913

Своп на HDD

Как там, в 2007? Зачем использовать что-то кроме свопа на zram? 15 гигов disksize можешь выставить. Одного устройства достаточно, они же много поточны. Nitin Gupta дал тебе божественный модуль zram, но ты зачем-то продолжаешь насиловать HDD.

с этой проблемой

с какой проблемой?

Итак, каковы итоги последних тестов?

Когда система встаёт колом при заполнении всей памяти и свопа.

А если памяти много, то есть смысл ставить этот патч? И как можно сравнить?

Если памяти много, но система на HDD, патч должнен значительно ускорить работу программ и переключение между ними при почти полном заполнении памяти.

Смотри https://bugs.launchpad.net/ubuntu/+source/linux/+bug/159356/comments/115 - памяти много не бывает, в конце концов бывают утечки.