Systemd 247 объединяет Systemd-OOMD для улучшения обработки нехватки памяти

Странно, как Поттеринг мог принять код, который написал не он.

Он многолик.

ждем рандомные килы и новую серию notabug и wontfix?

247 - будет еще отключен. Вообще пока хз, трудно сказать каким это будет в итоге. Как это будет управляться и настраиваться, какими будут пороги. Плюс некоторые ДЕ не собираются дробить свои сигруппы на части для отдельных приложений. Пока оомд не выглядит универсальным решением, которое можно будет воткнуть в любой десктоп и чтоб заработало хорошо. может будет ок для gnome, cinnamon, plasma

у остальных пока единая session-1.scope, в которой находятся все приложения

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

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

по площадям работают

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

А это, кстати, годно. Тот же электрон любит наплодить процессов. И если прибивать, то все процессы сразу, а не один, а потом ждать пока всё само сдохнет.

Отлично. Я ждал этого с нетерпением. Скорее в продакшон !

Только получается электрон надо запускать через systemd-nspawn или как его там?

В случае с браузерами таки логичнее начать с прибития обработчиков контента по одному, а не убивать все сразу. Примерно как здесь: https://youtu.be/PLVWgNrVNlc

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

R.I.P. GNU\Linux, heil GNU\Systemd!

systemd-kerneld coming soon...

Может быть просто не выделять память, если ее нет ?

хз как этот оомд будет без свопа реагировать. разрабы оомд требуют своп для его работы

Интересно, а Федора 33 переезжает на zram, по умолчанию своп-раздел предлагать не будут. Значит потом допилят.

https://fedoraproject.org/wiki/Releases/33/ChangeSet#swap_on_zram

своп-раздел предлагать не будут

Устройство zram - это своп-раздел.

Значит потом допилят.

Что допилят?

Ну, что? Твой велосипед теперь оправляется на помойку или ещё нет?

Еще нет.

1. oomd cannot kill separate processes. If you will use oomd with xfce, mate, lxde - it will kill all the session. oomd cannot separately kill you browser tabs.

2. oomd cannot send low memory warnings.

3. nohang works well with any DE. nohang supports GUI notifications.

4. nohang supports PSI.

nohang is best solution for desktop right now.

Новые велосипеды позволяют обходиться вообще без киллеров. При применении prelockd ядерный киллер начинает приходить вовремя.

Еще вот: https://ibb.co/tbk80q9

компиляю с -j1024, своп на HDD, параллельно смотрю ютубчики, фризов нет. Спрашивайте ответы.

При применении prelockd ядерный киллер начинает приходить вовремя

Ок, бодрячком тогда.

Но я, конечно, всё равно за то, чтобы всунуть больше оперативы. Ну, ты в курсе.

Понял, спасибо.

best solution

nope, дат бест солушн изъа ручной OOM killer, а автоматический, в любом виде — зло (если только машинка не оставляется надолго без присмотра и не должна стабильно работать при этом). А лучше вообще до убийств не доводить, а порешать мирно, загнав всё в своп, повыкидывав кэши и задрав Load Average за соточку.

порешать мирно

здесь инструменты описаны Просто оставлю это здесь: Игра в supertux2 с множественными `tail /dev/zero` в фоне без зависаний

Systemd 247-RC1 Released With Systemd-OOMD

R.I.P. GNU\Linux, heil GNU\Systemd!

Точнее будет Systemd/Linux. Ядро Линукс никто не отменял, а консольные GNU утилиты не критичны и заменяемы.

nope, дат бест солушн изъа ручной OOM killer, а автоматический, в любом виде — зло

+1. Ещё overcommit это зло. Это как билеты МММ, только для памяти.

Критические сервисы должны резервировать память перед запуском, чтобы никогда не было OOM. Вроде где-то была новость, что для DE (кажется Gnome) сделали такое резервирование но не могу найти.

uresourced

https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS

systemd-oomd

systemd-allo-yoba-eto-ty?

Никакой фантазии.

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

А остальное пускай падает, что ли?

И Вы так говорите, будто нужный для работы объём оперативы всегда можно предугадать заранее.

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

Угу, консольные утилиты уже на Rust переписывают вовсю. Осталось только в дистрибутив это собрать.

А остальное пускай падает, что ли?

Да. Матерелизатор памяти пока не изобрели. Падает или корректно обрабатывает ситуацию нехватки памяти и отменяет текущую операцию (например новое окно или вкладка не откроется). Если перестанет работать критический сервис, то система станет не пригодной к использованию и будет невозможно вручную завершить процесс потребляющий память.

И Вы так говорите, будто нужный для работы объём оперативы всегда можно предугадать заранее.

Для критических сервисов (GUI сервер, окружение рабочего стола, диспетчер задач) можно.

Systemd/Linux

Systemd/Systemd.

А вообще я бы на вашем месте, господа, провёл бы аудит кода этого oomd. Мало ли какие зонды Ящер Марк туда напихал.

Systemd/Systemd.

kerneld пока там не сделали.

kerneld пока там не сделали.

Ключевое слово – «пока».

Матерелизатор памяти пока не изобрели

Зато изобрели ненулевые коды возврата malloc и более высокоуровневые абстракции типа java.lang.OutOfMemoryException, которые программам следует обрабатывать корректно. Это куда проще, чем ловить утечки, которые могут произойти где угодно, и предсказывать размер входных данных, который априори неизвестен в общем случае.

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

Для этого есть резерв свободной памяти для рута.

GUI сервер, окружение рабочего стола, диспетчер задач

Они только у мышевозов критичны :) И у виндузятников без текстового режима (из-за чего Мы с винды и свалили).

Тот же электрон любит наплодить процессов. И если прибивать, то все процессы сразу, а не один, а потом ждать пока всё само сдохнет.

Т.е. какое-то там приложение — полное говно, а страдать должны остальные?

Зато изобрели ненулевые коды возврата malloc и более высокоуровневые абстракции типа java.lang.OutOfMemoryException, которые программам следует обрабатывать корректно.

В overcommit это не работает. Программа падает при обращении к якобы выделенной памяти.

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

Запускал давеча ghostrunner через steam/proton в F33 с кедами, компиляция шейдеров откушала 32гб памяти (из которых 4гб зрам свопа), и все (включая мышку) повисло где-то на полминуты. Непонятно, помог ли earlyoom, который там вроде как есть.

В overcommit это не работает. Программа падает при обращении к якобы выделенной памяти.

при overcommit=1 практически не падает, можно выделять терабайты. Но если физической памяти нет - может прийти киллер.

при overcommit=2 падает при невозможности выделения в зависимости от overcommit_ratio. При высоком overcommit_ratio также может приходить киллер. И невозможно подобрать универсальный overcommit_ratio для любых рабочих нагрузок.

Для этого есть резерв свободной памяти для рута.

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

The amount of free memory in the system that should be reserved for users with the capability cap_sys_admin.

А что если в конфиге dxvk ограничить количество потоков для компиляции?

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

Вроде только в воркстейшн, кеды еще не созрели.

компиляция шейдеров откушала 32гб памяти (из которых 4гб зрам свопа), и все (включая мышку) повисло где-то на полминуты

Советую использовать триаду хакавлада - nohang-desktop, prelockd, memavaild. Для федоры все это опакечено и есть в оф репах.

Непонятно, помог ли earlyoom, который там вроде как есть.

earlyoom не реагирует на высокое давление памяти. Выское давление можно детектить через метрики PSI, на которые способен реагировать nohang. earlyoom на них не реагирует.

См также Просто оставлю это здесь: Игра в supertux2 с множественными `tail /dev/zero` в фоне без зависаний

А что если в конфиге dxvk ограничить количество потоков для компиляции?

Очевидно, это хорошая идея, если памяти не хватает.

Я понятия не имею как это сделать в стиме

Приглашаю в чат, где помогут эксперты - https://matrix.to/#/+gaming-ru:matrix.org

Я похоже нашел в чем дело

https://github.com/ValveSoftware/Fossilize/issues/84#issuecomment-718101379

Память жралась как раз процессами fossilize_replay. У меня 16 ядер (виртуальных, 8 физических), так что makes sense. Обещают что-то пофиксить скоро

R.I.P. GNU\Linux, heil GNU\Systemd!

вот уж точно не GNU. corp/Systemd или facebook/Systemd или IBM... но точно не гну уже.

Странно, как Поттеринг мог принять код, который написал не он.

это также странно, как и то, что когда поттер написал networkd, его не стали использовать в самом RHEL с остальным systemd.

а facebook - основной пользователь systemd. мне даже кажется, что потер не сам это все придумал, а в сотрудничестве с ними и с учетом их хотелок. я думаю и багрепорты он в основном от них разгребает (а все прочие игнорит).

в нормальном мире у фейсбуков должен был бы выйти свой дистрибутив на основе systemd. но почему они решили его впарить всем - для меня загадка.

Т.е. какое-то там приложение — полное говно, а страдать должны остальные?

Ага. Нахрен такая система если её какое-то приложение может её повесить?