LINUX.ORG.RU

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

 , , ,


3

4

Тред https://forum.xanmod.org/thread-4102-post-7572.html

Патч https://github.com/hakavlad/le9-patch

В чем дело?

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

Решение: запрет на вытеснение определенного объема файловых страниц. Это обеспечивает этот самый патч, и киллер приходит быстро, система не виснет.

Патч принят в pf-kernel и linux-xanmod. linux-xanmod предоставляет бинарные сборки для deb-дистрибутивов.

Скачать бесплатно https://xanmod.org/

Ответ на: комментарий от ValdikSS

Сделал отдельную заметку: https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/

По ссылке есть образ LiveCD Mint XFCE 20.1 с le9 и zram, для теста.

ValdikSS ★★★★★ ()
Последнее исправление: ValdikSS (всего исправлений: 1)
Ответ на: комментарий от hakavlad

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

Нет времени для тестов, работа.

Вчера грузил систему через tail /dev/zero. Ситуация получше, чем на ванильном ядре, но далека от того, что я предпочел бы видеть.

wandrien ()
Ответ на: комментарий от hakavlad

Как я предполагаю, следующим бутылочным горлышком является приоритизация IO. Условный tail /dev/zero уже не мешает размыванию списка чистых страниц, но мешает загрузке-выгрузке анонимной памяти других процессов.

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

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

wandrien ()
Ответ на: комментарий от wandrien

zram займёт всю оперативку?

Не займет, если применять nohang c конфигом zram_checking_enabled=True. Также есть версия le9, защищающая мин объем анонимной памяти (патч не опубликован, однако пользуюсь сам именно им).

https://www.youtube.com/watch?v=o6GOz95sAnY

если данные хорошо сжимаются - улетят в своп

если плохо - zram займет много оперативы и оффендер будет убит

hakavlad ★★ ()
Ответ на: комментарий от wandrien

https://github.com/hakavlad/nohang-extra/blob/master/LE9/276.patch

а вот и патч

как тебе такое, @post-factum

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

hakavlad ★★ ()
Ответ на: комментарий от wandrien

кроме него никто даже приблизительно не понял, о чем речь

Был адекват на опеннете еще:

Начинает тормозить потому что:
1. линуксу некуда деть анонимную память (свопа нет)
2. Единственно что можно выгрузить - это замеморимапленные с диска файлы. Например, запущенные программы и библиотеки.
3. Так как они по факту таки используются, то он их постоянно читает с диска, чуть поюзает и выбрасывает из памяти.
4. Потому что никто, блджад, не использует mlock() / mlockall() а надо! 

https://www.opennet.ru/openforum/vsluhforumID3/118068.html#6

Потому что никто, блджад, не использует mlock() / mlockall()

prelockd как раз решает проблему через mlockall()

hakavlad ★★ ()
Ответ на: комментарий от wandrien

Это worst case, от которого пляшем.

Зачем искусственно создавать worst case, если этого легко избежать? хромос, андроид и федора предпочитают своп только на zram. И многие другие дистрибутивы тоже.

zram - это наступивший мейнстрим, от которого и надо отталкиваться.

без внешней подкачки придёт киллер во время интенсивной компиляции

Вот сборка с -j512, никто не умер https://www.youtube.com/watch?v=nSCT_zZHYYQ

anonymous ()
Ответ на: комментарий от wandrien

в файле подкачки

О Иисус, зачем использовать файл подкачки?

штраф на IO

тейлу практически не нужен IO. - Штраф получают процессы гуя, когда вытесняются их либы из памяти. От этого и зависит в основном - зависнет ли гуй или нет если своп на zram. Со swappiness=200 гуй не виснет, если нет подкачки на диске.

anonymous ()
Ответ на: комментарий от post-factum

Ну ужас, но не «Ужас-ужас.». Каковы аргументы? Плох алгоритм? Плоха идея? Идея защиты анонимки кажется абсурдной? Но на дворе не 2010 и защита анонимки - важная задача.

Да, в 2010 была такая шутка:

swap would be intersting if we could somehow control swap thrashing. Maybe
we could add min_anonlist_kbytes. Just kidding:)

https://lore.kernel.org/patchwork/patch/222042/

Но в 2021 это жизненная необходимость.

anonymous ()
Ответ на: комментарий от anonymous

Твой пример не ущербен в условиях маленькой и ОЗУ, а также в другом случае при прожорливом процессе готовом заполнить и 200-300 ГБ того что ему будет доступно в виде ОЗУ и/или подкачки.

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

Сейчас уже времена далеко после пентиума три и 128мб озу.
Двухъядерные ЦП очень распространены, озу минимум 2ГБ — в таких условиях нет причин выгружать графику и делать систему не отзывчивой и тем более позволять одному процессу совершенно бесконтрольно заполнить всю доступную память и при этом недоступную тоже (!) путём выгурзки кода «второго сорта», это просто бред, как ты на это не посмотри.

Подкачка будь то на диске или в ОЗУ как и исчерпание памяти вообще не должно влиять на отзывчивость графического интерфейса, 2021 год на дворе.

Exmor_RS ★★ ()
Последнее исправление: Exmor_RS (всего исправлений: 1)
Ответ на: комментарий от Exmor_RS

Подкачка будь то на диске или в ОЗУ как и исчерпание памяти вообще не должно влиять на отзывчивость графического интерфейса, 2021 год на дворе.

а кто с этим спорит? с каким невидимым собеседником споришь, отвечая на мои сообщения?

anonymous ()
Ответ на: комментарий от anonymous

Вот сборка с -j512, никто не умер

Я вот сейчас утром к компу подошел, а там вся оперативка занята, и 4 гига в свопе. А мне некогда смотреть, кто течет и почему — работать надо. Такие дела.

wandrien ()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

Так обычно и происходит - в своп идут неактивные страницы. Однако механизм выбора неактивных страниц может быть несовершенен, вследствие чего и предложен Multigenerational LRU Framework.

anonymous ()
Ответ на: комментарий от anonymous

Проблема решается отключением подкачки на диск. Зачем создавать проблему в виде медленной подкачки, а потом жаловаться на нее?

Я уже выше говорил, проблема решалась простым патчем на ядро в версии 4.xx-какой-то. Если будет время, повторю под современным.

Так не суй себе палку в колеса. Напоминаешь велосипедиста из известного комикса.

Напоминает аргументы отрицателей зависонов линукса:

Так не запускай жирные процессы, если мало памяти! Купи еще памяти!

wandrien ()
Ответ на: комментарий от ValdikSS

Пользователи ищут исправление зависаниям по меньшей мере с 2008 года (bug 12309 https://web.archive.org/web/20200206024633/https://bugzilla.kernel.org/show_bug.cgi?id=12309 ). Эта проблема настолько распространена и очевидна, что про неё есть статья на lurkmore, а её обсуждение из года в год поднимается среди профессионалов https://www.opennet.ru/opennews/art.shtml?num=51231 .

Так это ж две разных проблемы.

12309 - проблемы при копировавнии. Во втором случае - отказ в обслуживании при дефиците кэша (хотя первая проблема может быть частным случаем второй - нехватка кэша может провоцироваться копированием (чистый кэш вытесняется грязным)).

anonymous ()
Ответ на: комментарий от wandrien

проблема решалась простым патчем на ядро в версии 4.xx

Что за проблема? Что за патч?

Напоминает аргументы отрицателей зависонов линукса:

Так не запускай жирные процессы, если мало памяти! Купи еще памяти!

Это у тебя странная аргументация:

Я сделал своп на HDD, и система виснет!

Из серии:

Я сделал swappiness=0 и система виснет! Я выключил юзерспейсные киллеры, и система виснет! Я использую все худшие практики, и система виснет!

Так зачем ты используешь худшие практики? Используй лучшие практики вместо худших.

anonymous ()
Ответ на: комментарий от anonymous

Это у тебя странная аргументация

У меня аргументация нормальная. Жрущий процесс не должен оказывать существенного влияния на отзывчивость других компонент системы вне зависимости от деталей конфигурации системы подкачки.

Это вопрос приоритетов, а не тупых крутилок-костылей типа swappiness.

Это у тебя странная аргументация: Я сделал своп на HDD, и система виснет!

«Странная аргументация: я запустил процесс без yield(), и система виснет! Так не запускай процессы без yield(). Ты что, не знаешь, как многозадачность устроена?»

В отличие от 1985-го, сейчас мультиплексирование CPU не требует костылей в виде yield(). А вот мультиплексирование памяти под линуксом все еще требует обвешаться тонной костылей и точно знать, за какие красные флажки нельзя заходить. Иначе кирдык башка, зависон, reset.

Что за проблема? Что за патч?

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

wandrien ()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Жрущий процесс не должен оказывать существенного влияния на отзывчивость других компонент системы

Допустим.

вне зависимости от деталей конфигурации системы подкачки

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

anonymous ()
Ответ на: комментарий от anonymous

А вот тут есть варианты: своп на медленной подкачке или на быстрой.

Подкачка кому из них нужна: tail, который дожирает 9-й гигабайт памяти из 8-ми ГБ доступных в ОЗУ (лол), или терминалу, который и 100 метров не занимает?

wandrien ()