LINUX.ORG.RU

Первый релиз юзерспейсного OOM-киллера - oomd 0.1.0

 , ,


2

3

Разработка Facebook нацелена на более оперативное и выборочное завершение работы процессов, потребляющих слишком много памяти, на стадии до срабатывания OOM-обработчика ядра Linux. Код oomd написан на языке C++ и поставляется под лицензией GPLv2. Oomd уже используется в инфраструктуре Facebook и хорошо зарекомендовал себя при промышленных нагрузках (в частности, проект позволил почти полностью избавиться от возникновения на серверах длительных livelock-блокировок). Подробнее о работе oomd: https://facebookmicrosites.github.io/oomd/

>>> Подробности

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

система встала раком, я такой, ну ладно, глянем что будет ушёл по делам вернулся через часа 4 всё тоже раком стоит, память в нуль 6 ядер на 100% своп на половину. И никто никого не прибил, ну я чё ладно, через termux зашёл (ибо графика тупо висела и мышка сдвигалась раз в 10 секунд)

Киллер не пришел, потому что не было OOM. В вашем случае был полупустым своп. Система фризилась, потому что шло интенсивное использование свопа и была конкуренция за память. Такие проблемы как описана у вас как раз лучше обрабатывать в юзерспейсе с использованием метрики PSI (появилось в ядре 4.20, реакция на метрику PSI поддерживается в oomd и nohang).

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

после того, как появились cgroups было бы логично переписать ядерный OOM

Вообще-то OOMK может работать в отдельных сигруппах. Если сигруппе задано ограничение по памяти, то при ее исчерпании процессы убиваются только внутри этой группы в сообветствии со своими oom_score.

Более того, Linux 4.6 (released in May 2016) introduced changes in OOM situations, improving detection and reliability.[2][3], cgroup awareness in OOM killer was implemented in Linux Kernel 4.19 released in October 2018, which adds an ability to kill a cgroup as a single unit [4]. https://en.wikipedia.org/wiki/Out_of_memory

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

Вот только встающая раком система при нехватке ОЗУ не миф. А тут линукс себя ведёт весьма плохо.

RT ядра на Дебиан Бустер ведут себя хорошо, но ценой замедления системы

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

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

Шансы очень высоки. Ни разу не видел смерти earlyoom, даже если не выставлять oom_score_adj=-1000 (сам earlyoom потребляет меньше мегабайта и практически невидим для киллера). Доводилось наблюдать смерть nohang при длительных стресс-тестах при работе в сигруппе с ограниченной памятью в условиях порождения множества ГУИ уведомлений (процессы notify-send весят меньше, чем интерпретатор python). В естественных условиях смерть от руки киллера практически исключена. oomd не тестировал, так как не осилил установку.

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

Спасибо, попробую этот рецепт.

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

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

Ничего не понимаю… И это линуксадмины? ***** какое-то, ******, *****. Программисты дали им юзерспейсные обработчики — пользуйся! Пользуйся юзерспейсными обработчиками, *****! Не хочу, хочу жрать *****! Что такое? Это линуксадмины?! Это линуксадмины?! ****… ******* — админы. Линуксы установили, ***** жрут — ******, *****, ******…

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

RT ядра на Дебиан Бустер ведут себя хорошо, но ценой замедления системы

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

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

Ну мне со своими хромами и фирефоксами до паралича системы как рукой подать, одна проблема, омкилер не срабатывает.
Но вот rt ядра сопротивляются, не дают отжать все ресурсы.

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

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

Как раз для этого и создан earlyoom: «The oom-killer generally has a bad reputation among Linux users. This may be part of the reason Linux invokes it only when it has absolutely no other choice. It will swap out the desktop environment, drop the whole page cache and empty every buffer before it will ultimately kill a process. At least that's what I think what it will do. I have yet to be patient enough to wait for it, sitting in front of an unresponsive system.

This made me and other people wonder if the oom-killer could be configured to step in earlier: reddit r/linux, superuser.com, unix.stackexchange.com.

As it turns out, no, it can't. At least using the in-kernel oom-killer. In the user space, however, we can do whatever we want.

What does it do

earlyoom checks the amount of available memory and free swap to to 10 times a second (less often if there is a lot of free memory). By default if both are below 10%, it will kill the largest process (highest oom_score)» https://github.com/rfjakob/earlyoom

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

современных технолоний

Современные технологии — это выносить одну из основных задач ядра в юзерспейс? Серьёзно? Да по тебе Кащенко (не тот, который наш, а тот, который психиатрическая больница) плачет!

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

выносить одну из основных задач ядра в юзерспейс?

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

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

Если ядру плевать на проблемы юзерспейса

К чёрту такое ядро.

ждать сто лет, когда ядерные ребята наконец сподобятся реализовать

Пусть фанатики-сектанты становятся на колени и вымаливают то, что обязаны были получить по умолчанию. Или ваяют костыли типа сабжа.

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

October 2018, which adds an ability to kill a cgroup as a single unit

да, вроде это как раз то, что фейсбук обозначает фичей своего OOM killer'a. а почему я тогда не вижу memory.oom.group вот просто так, из коробки?

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

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

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

это как раз то, что фейсбук обозначает фичей своего OOM killer'a

Да вроде нет. 'kill a cgroup as a single unit' - это не про фейсбуковский oomd.

почему я тогда не вижу memory.oom.group вот просто так, из коробки?

Это должно работать только с cgroup2 на ядрах 4.19 и новее. Соблюдаются ли у вас эти условия?

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

основная фишка этого киллера в его конфигурабельности что ли

Разумеется! Основная проблема ядерного киллера - его трудная и низкая настраиваемость. Практически нельзя заставить киллера срабатывать раньше. Безальтернативный SIGKILL. Неудобная расстановка приоритетов процессам с необходимостью персонального прописывания oom_score_adj.

Эти проблемы и пытается решить oomd: «oomd leverages PSI and cgroupv2 to monitor a system holistically. oomd then takes corrective action in userspace before an OOM occurs in kernel space. Corrective action is configured via a flexible plugin system, in which custom code can be written. By default, this involves killing offending processes. This enables an unparalleled level of flexibility where each workload can have custom protection rules.»

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

Это должно работать только с cgroup2 на ядрах 4.19 и новее. Соблюдаются ли у вас эти условия?

да, конечно

dell ~ # mount -t cgroup2 none /mnt/
dell ~ # uname -a
Linux dell.inter 4.20.6-100.fc28.x86_64 #1 SMP Thu Jan 31 15:51:26 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
dell ~ # sysctl -a 2> /dev/null |grep memory.oom.group
dell ~ # 

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

Да вроде нет. 'kill a cgroup as a single unit' - это не про фейсбуковский oomd.

ну как нет-то. вот же, по ссылке:

Another complication was that the kernel OOM killer would kill just one of a build job’s processes. Since the build job can't function without the dead process, it’s left in an undefined state. ... The solution — controlled cgroup OOM kills with oomd

https://facebookmicrosites.github.io/oomd/docs/oomd-casestudy.html

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

Именно то, чего в псоледнее время как раз не хватает. У меня OOM Killer вообще ни разу не сработал, резетом только диски убиваю. Кто-нибудь уже опробовал?

лучше earlyoom попробуй

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

Даже близко не линуксадмины.
да и очень не хочется юзать самопальные юзерспейсные киллеры при наличии кернелспейсного. Но придётся, да.
Да и ловлю я эти OOM раз в полгода при запуске виртуалки с виндой при запущенном гноме и хроме с несколькими десятками вкладок (и здесь могу посоветовать полезное расширение - The Great Suspender).

das_tier ★★★★★ ()

Протестировал oomd на Fedora 29 с desktop.json. VmRSS около 2 MiB. mlockall() не выполняется, процесс может уйти в своп. Состояние памяти проверяется раз в 5 секунд, но на процессор это заметно влияет, дольки процента в htop проскакивают. Работает только от рута. Если запустить с интервалом 1 сек, то может нагрузить проц на целый 1% (это больше, чем грузит nohang, который на питоне). Не удалось наблюдать oomd в действии: ядерный OOMK срабатывал раньше, хотя oomd писал, что пытается действовать.

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

почему я тогда не вижу memory.oom.group вот просто так, из коробки?

«Controlling Controllers -----------------------

Enabling and Disabling ~~~~~~~~~~~~~~~~~~~~~~

Each cgroup has a „cgroup.controllers“ file which lists all controllers available for the cgroup to enable::

# cat cgroup.controllers cpu io memory

No controller is enabled by default. Controllers can be enabled and disabled by writing to the „cgroup.subtree_control“ file::

# echo »+cpu +memory -io" > cgroup.subtree_control

Only controllers which are listed in «cgroup.controllers» can be enabled." https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git/tree/Documentat...

У вас контроллер памяти не включен.

hakavlad ()
Ответ на: Больше костылей богу костылей! от mord0d

Это к тебе не прибегали горе-вордпрессеры с криками «Я тут клиенту поставил на самый дешевый дроплет DO вордпресс, а оно что-то падает. ПАМАГИТЕ!». Заходишь туда, заглядываешь в dmesg, а там OOM обжил себе уютную квартирку, то мускулю по голове даст, то nginx схлопочет, то php-fpm пришибет :-D :-D :-D

Nill ()