LINUX.ORG.RU

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

 , , ,


5

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

У меня 16 Gb , но её я редко всю использую. Cтавить патч не имеет смысла наверно. И да - HDD.

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

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

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

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

Это ж исправляется элементарно. Кто-то еще подвержен проблеме в 2021?

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

не всякая полезная работа столько сожрёт. на самом деле жрёт больше всего у меня как раз баловство(не игры)

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

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

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

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

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

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

Ну при работе без внешней подкачки придёт киллер во время интенсивной компиляции, убьет мне браузер… Так не интересно.

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

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

Почему бы не поставить своп в zram и disksize= 2MemTotal? Какие с этим проблемы?

hakavlad ★★★ ()
Ответ на: комментарий от 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 ★★★ ()
Ответ на: комментарий от Exmor_RS

Ну переписывание вроде и не планируется. Что не так с питоном? Без питона есть le9 патч - естественная альтернатива prelockd, не требующая демона.

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

Я не так выразился, а ты не так понял: меня версия на питоне полностью устраивает.

Exmor_RS ★★★ ()
Ответ на: комментарий от 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

где я писал, что гуй не важен?

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

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

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

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

бесконтрольно заполнить всю доступную память и при этом недоступную тоже (!)

Что такое недоступная память?

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

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

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

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

«Всё есть файл» (с)

Со swappiness=200 гуй не виснет, если нет подкачки на диске.

А с подкачкой на диск виснет. Проблема не решена.

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

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

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

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

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

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

А мне некогда смотреть, кто течет

в таком случае проблему решит Alt+SysRq+K

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

А с подкачкой на диск виснет. Проблема не решена.

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

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

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

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

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

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

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

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

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

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

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

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

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

Покажет кто течет.

У меня только Xorg занимает 1.5G RSS и не худеет до полного ресета сеанса. Течет, ясен пень, не Xorg, а клиенты.

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 ()
Ответ на: комментарий от wandrien

9-й гигабайт памяти из 8-ми

ШТО

Подкачка кому из них нужна

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

anonymous ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.