LINUX.ORG.RU
ФорумTalks

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

 


0

1

Всего несколько часов назад слился [1] с systemd Git - новый компонент systemd-oomd, продвигаемый Facebook.

Systemd-oomd был разработан для улучшения поведения Linux, связанного с нехваткой памяти / давлением памяти, и основан на коде демона нехватки памяти Facebook, который был расширен для работы не только с серверами Linux, но и с настольными системами.

Демон systemd-oomd опрашивает контрольные группы с поддержкой OOMD для мониторинга и завершает работу в зависимости от нехватки памяти или использования подкачки. Поведение systemd-oomd можно настроить с помощью нового файла конфигурации oomd.conf. Этот демон будет уничтожать группы только в том случае, если EnableOomdKill установлен как явно не желающий убивать случайные процессы из-за использования памяти. Другие новые настройки включают параметры ManagedOOMSwap=, ManagedOOMMemoryPressure= и ManagedOOMMemoryPressureLimitPercent=. Команда oomctl используется для анализа состояния systemd-oomd.

Для первоначального выпуска systemd 247, в котором проходит премьера, systemd-oomd будет отключен по умолчанию и требует установки -Dmode=developer во время сборки для активации режима разработчика. По крайней мере, на данный момент это считается функцией предварительного просмотра и все еще дорабатывается, поэтому на данный момент не рекомендуется для производственных сред.

Слияние составляет чуть более трех тысяч строк нового кода.

Разработчики Systemd работают над подготовкой systemd 247 к выпуску в ближайшие недели.

  1. https://github.com/systemd/systemd/commit/69c0807432fa4fbfbf507a53872664cd26715559
★★★

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

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

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

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

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

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

hateyoufeel ★★★★★
()

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

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

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

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

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

hakavlad ★★★
() автор топика

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

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

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

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

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

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

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

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

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

Что допилят?

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

Еще нет.

  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.

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

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

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

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

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

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

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

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

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

best solution

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

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

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

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

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

Systemd 247-RC1 Released With Systemd-OOMD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Systemd/Linux

Systemd/Systemd.

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

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

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

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

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

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

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

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

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

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

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

deep-purple ★★★★★
()
Ответ на: комментарий от mertvoprog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

hateyoufeel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.