Современное состояние обработки нехватки памяти в линуксах: MGLRU и le9 патчи и юзерспейсные киллеры

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

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

Нет. Глупости какие.

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

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

счет смерти одного процесса.

Как oom-киллер будет определять какой процесс надо убить?

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

адекватного свопинга

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

в этом и плюс юзерспейсных киллеров - их можно максимально гибко настроить.

Пользовательские OOM-killer (earlyoom, nohang) отличаются от дефолта наличием большого количества тонких настроек. Можно выставить приоритет приложениям. Можно, наверно, выставить запрет на убийство, и тогда killer будет сыпать предупреждениями о критической нехватке памяти, пока система не повиснет намертво.

Пример для earlyoom, из моего старого /etc/default/earlyoom:

EARLYOOM_ARGS="-m 5 -r 3600 -n --avoid '(^|/)(init|systemd|Xorg|sshd)$' --prefer '(^|/)(qemu|Web Content)$'"

У меня qemu используется только для просмотра iso, поэтому первый в очереди на убийство. Затем вкладки браузера, причем дефолтный так не умеет и грохнет все окно (или уже умеет?).

p.s. Перешел на nohang, в основном из-за zram_checking_enabled = True.
Этот OOM-killer в разы сложнее в настройках, чем все остальные, имхо. Наверно, автор старался учесть все нюансы поведения системы в режимах нехватки памяти. Так что, я даже туда не лезу, изменил один параметр и пока достаточно. :)

в этом и плюс юзерспейсных киллеров - их можно максимально гибко настроить.

Пока набирал свою ‘простыню’, автор выразил все в одном предложении. )

от них польза на десктопе
на сервере сомнительно
а в случае поведения в PVE - вообще нонсенс.

оомд как раз написан для серверов

см зачем https://engineering.fb.com/2018/07/19/production-engineering/oomd/

первый в очереди на убийство

Добавлю, что с использованием le9/MGLRU, уже забыл, когда последний раз был приход OOOM-killer или зависала система.

*Ядро pf-kernel, поэтому речь о MGLRU. Железо одно и тоже, особенности использования системы не изменились. Возможно, дело в связке zram+nohang+MGLRU.

на сервере вообще не должно быть такого явления как ООМ, тем более в сервере виртуализации.

правильно, ООМ надо предотвращать, для этого и существуют обработчики нехватки памяти

Своп не бесконечный

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

да и лагает система

Лучше небольшие неудобства чем крах вкладок браузера или ещё что похуже.

Из этого треда сложилось впечатление, что злой OOM-killer незаслуженно убивает важные процессы у добропорядочных пользователей. )

нет, для этого существует планирование ресурсов.

оомд - это не только убийца, но и детектор проблем и кастомный обработчик этих проблем.

Современное состояние обработки нехватки памяти в линуксах: MGLRU и le9 патчи и юзерспейсные киллеры (комментарий)

Только и слышно, oom-killer такой, oom-killer сякой. Но ведь никто не заставляет отстраненно смотреть как он убивает важные процессы. Это звоночек, когда можно и нужно принять важные решения и шаги по перенастройке системы или даже железному апгрейду.

Но и наверно можно настроить пользовательские oom-killer, чтобы они сигнализировали по всем возможным каналам о проблеме. Это к вопросу о серверах и важных процессах, которые как я понял уж лучше бы зависли…

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

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

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

Таки на сервере. ... если один из процессов отожрал все ресурсы

то у тебя хреновое планирование ресурсов или тебя кто-то поимел.

На десктопе очень редко можно столкнуться с ситуацией, что софтина внезапно всё сожрала

о даа! расскажи это браузерам, у меня как-то раз вкладка с ютубом отжрала 2+ гига, а у Teams снесло крышу и он выжрал больше 4 гиг.

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

https://www.phoronix.com/news/MGLRU-v14-Released ВЫШЕЛ

https://lore.kernel.org/lkml/20220815071332.627393-1-yuzhao@google.com/

ну всё https://www.phoronix.com/news/MGLRU-MM-Branch

Очередная комплиментарная статья об MGLRU, MGLRU выглядит как одна из лучших инноваций года в ядре Linux. Со скринами бенчмарков и два видео презентаций на en.

Скоро, очень скоро все это будет дефолтно в ванильном ядре и больше никто не скажет подобные кощунственные слова :)

Я наверное вас огорчу, красноглазики, но Windows 10 на одной и той же конфигурации работает побыстрее чем Linux. Возможно конфигурация нужна пожирнее, но вот управление процессами, памятью и свопом организовано так, что если запустилась Винда - то на ней запустится и офис с браузером.
Особенно эта разница видна на действительно слабых девайсах (древний != слабый).
Так вот откуда идут мифы о том, что линукс - система для слабых компов! (комментарий)

Пушка. Наконец дожили.

Своп не бесконечный

Имея тебебайтный диск его можно считать таковым.

Имея терабайтный SSD в ноуте, я его уже на 80% занял данными ;)

А вот имея терабайтный диск, использовать его как своп в 2022 — удачи…))

диск, использовать его как своп в 2022 — удачи…)

Собственно прошло 1,5 года, как у меня последний диск перестал быть свопом. Причём он был не терабайтным, а 160Гб 2,5". И та схема тоже работала, хотя и требовала внимательно думать сколько вкладок ты собираешься открыть.

Имея терабайтный SSD в ноуте, я его уже на 80% занял данными

Примерно 3 года назад на другом моём ноуте винда убила ssd активным своппингом по 2 гигабайтам. С тех пор я резервирую под своп-раздел на ssd как минимум 20Гб, даже если это 18% всего ssd. Так что выделить 5% от терабайтного вполне реально.

что-нибудь

Ключевая проблема

хреновое планирование ресурсов

Инфинити луп с пожиранием памяти в юниттесте на билд-ферме. Как ты его запланируешь?

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

В чем проблема с 4мя гигами?

убила ssd активным своппингом по 2 гигабайтам

Это что за унылый сисиди без размазывания данных по ячейкам и без резервной области?

Это любой ssd, хронически занятый на 90%. Причём те два гектара почти 2 месяца утюжила жирная игрушка и возможно драйвер amd dual grafic.

Инфинити луп с пожиранием памяти в юниттесте на билд-ферме.

А что делает этот тест, тестирует билд-ферму на оом?
Если нет, то как этот код туда попал?

В чем проблема с 4мя гигами?

Ну.. если у тебя много свободной оперативы то нет проблем.

а swap on zram для кого придумали?

Дай угадаю, ты никогда не писал юнит тестов.

Для тех у кого полно оперативы и им не нужен своп?

Вместо вангования на вопрос ответь.

На Анроид-мобилках полно оперативы?

Уже.

Мне кажется для серверов придумали, чтобы всячески экономить место и оборудование, потом уже для мобилок адаптировали.

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

Ни своп, ни зрам, не помогают в ситуации когда у тебя жизненно важные библиотеки тупо вытесняются из ОЗУ.

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

Такая система раком встанет и на 2ГБ и на 2ТБ.

Ни своп, ни зрам, не помогают в ситуации когда у тебя жизненно важные библиотеки тупо вытесняются из ОЗУ.

Очень удачный выбор, написать такое в теме, где обсуждается и MGLRU/le9. )

prelockd one love

le9 удален из ядра xanmod начиная с 5.19-xanmod. По умолчанию там теперь MGLRU. le9 остался там в 5.15 LTS.

Читай выше, игрушка на винде.

еще не все дистрибутивы используют своп на zram.

Прогресс не стоит, ) разрабы норовят еще больше данных впихнуть в zram.

… zram может выиграть, когда использует комбинацию алгоритмов: алгоритм по умолчанию, который быстрее, но имеет более низкую степень сжатия, и вторичный алгоритм, который может использовать более высокую степень сжатия за счет более медленного сжатия/декомпрессии.

Инженер Google экспериментирует с обработкой ZRAM для нескольких потоков сжатия

Новые патчи MGLRU для Linux улучшают масштабируемость Global Reclaim

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

Linux 6.1 выпущен с MGLRU.

Вот и наступил тот самый день. :)

Я думаю, с ядра 6.1 мы вступаем в новую эру. Когда многие на практике увидят, что при ‘исчерпании’ физической памяти комп не тормозит и не виснет. С учетом, конечно, подключенного свопа (zswap/zram), а то некоторые умудряются дать ему отставку, типа ну у меня же столько памяти…)
Раньше решалось хардварно (добавлением планок), теперь будет софтово. Все эти огромные объемы RAM на десктопах можно будет делить на два, без потери комфорта.
Сколько оперативной памяти установлено на ваш основной личный ПК/ноутбук/моноблок? (комментарий)

кстати gitlab.com/post-factum/pf-kernel Page Not Found

Переехал на codeberg

Теперь на pfkernel.natalenko.name. Уже «release: v6.1-pf1», и, соответственно, из списка примененных патчей убрана запись о MGLRU.

на диск упадут только несжимаемые страницы, а не все подряд, как при использовании zswap.

Но про zswap пишут аналогичное, т.е. несжимаемые страницы сразу идут в своп.

«ZSWAP: … If the block is not compressible, then the data gets written to the disk/SSD swap straight-away.»

https://superuser.com/questions/1727160/zram-vs-zswap-for-lower-end-hardware

https://www.reddit.com/r/linux/comments/vm001m/guide_setting_up_zswap/

«But zswap does not compress pages which are incompressible, instead sending them to your swap file.»

(Хотя автор, видимо, один и тот же)

Здесь есть обсуждение:

zram и zswap или что то ещё,вместе? (комментарий)

киллер, убить...

Почему нельзя сформулировать: какой процесс надо завершить?

Спрашивайте ответы.

Начиная со сколько памяти можно отключать своп?