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

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

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

твой ноутбук и твои пожелания никого не волнуют.

Вообще-то в oomd есть конфиг для десктопа: https://github.com/facebookincubator/oomd/blob/master/etc/desktop.json

после того, как появились 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

а сразу юзерспейс ограничить слишком просто?
man systemd.resource-control

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

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

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

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

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

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

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

Вся суть фанатиков.

Игнорирование современных технолоний корректной обработки нехватки памяти - вся суть луддитов.

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

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

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

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

Как раз для этого и создан 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разумеется! Основная проблема ядерного киллера - его трудная и низкая настраиваемость. Практически нельзя заставить киллера срабатывать раньше. Безальтернативный 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.»

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

Это должно работать только с 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 ~ # 

Да вроде нет. '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

sysctl -a

Мне кажется не там ищете. Это ж вроде должен быть файл в каждой наблюдаемой сигруппе. Может стоит попробовать find /sys/fs/cgroup | grep oom

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

окей, плохо читал

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

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

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

Спасибо, тоже испытаю. Благо, в Debian 10 есть в репах.

самопальные юзерспейсные киллеры

earlyoom давно уж у людей в продакшне крутится.

при наличии кернелспейсного

который у вас не срабатывает

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

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

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

oomd без плагинов - груда металлолома. Будет юзабелен когда появится пакет oomd-plugins

Вообще-то core plugins включены в oomd.

VmRSS около 2 MiB

На самом деле около 4.5 MiB.

ядерный OOMK срабатывал раньше, хотя oomd писал, что пытается действовать.

Создал issue https://github.com/facebookincubator/oomd/issues/61

У меня OOM Killer вообще ни разу не сработал, резетом только диски убиваю.

Вместо ресета жми SysRq+Alt+F, мне в последнее время помогает.

мне не помогало, потому что не было включено в ядре по дефолту

почему я тогда не вижу 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...

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

можешь показать на себе

https://imgur.com/a/e4fd5lO

ага, понятно, спасибо. почитаю)

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