oom killer в systemd

Пажжите, но ведь федоровцы уже собрались включить какой-то другой оом-киллер. У них будет битва?

У них будет битва?

у киллеров? пустить обоих, посмотреть кто кого? ну неплохо, неплохо.

юзерспей реализация oom killer

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

Скажите мне, а в чем проблема настроить ядреный oom killer?

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

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

Да, чувак, ты круче пейспука.

Я сначала киляю телеграм, после него - браузер. Я бы сказал, что наличие запущенного телеграма оставляет возможность жить браузеру.

телеграм

У тебя 1 ГБ оперативы?

Когда я обнаружил, что ядерный не работает, я написал свой юзерспейсный

Пакажи. Ядрённый настраивать ненужно? Там не earlyoom, не?

Время убивать (комментарий)

думаю демонизировать тоже просто

Перечитал свой древний тред Время убивать (комментарий). Ржу.

Кто-то обязательно напишет. И назовет oomd.

alchemist ★ (12.12.16 15:09:59)

В андроиде вроде он хорошо работает

В андроиде тоже юзерспейсный, свой.

Спасибо

но ведь федоровцы уже собрались включить какой-то другой оом-киллер. У них будет битва?

Как ты думаешь, где именно Леннарт сказал то что описано в топ-посте?

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

После обсуждения происходит голосование FESCo по вопросу делать или не делать. И так по каждому сколько-нибудь интересному изменению. Так что это не «битва», а рабочий процесс.

Оно же на C++. Ленарт перепишет его на православный C for Linus’s sake?

8

федоровцы уже собрались включить какой-то другой оом-киллер

Да. earlyoom - зрелый, отлично работающий продукт, обеспечивающий корректное завершение процессов через SIGTERM.

У них будет битва?

Лёнин systemd-oomd еще не явился на ринг. Фейсбучный oomd сильно жрет процессор и жестко убивает только целые контрольные группы.

обеспечивающий корректное завершение процессов через SIGTERM

Кстати вопрос, почему вторым шагом идёт SIGKILL, а не дёргается oom?

Этому есть какие-то технические препятствия?

Хочется чтобы если SIGTERM не помог, то поведение системы было таким же как при kernel oom. Чтобы разные механизмы реакции на oom-события не конфликтовали.

Кажется, нет технической возможности дёрнуть OOM-киллер для конкретного процесса.

oom_score_adj=1000 прописать и дёрнуть. Так можно освободдать память процессов в состоянии D.

Кстати вопрос, почему вторым шагом идёт SIGKILL, а не дёргается oom?

ядерный может просто не срабатывать. https://github.com/rfjakob/earlyoom/issues/80

Low memory! mem avail: 380 of 5875 MiB (6) % <= min 10 %, swap free: 0 of 0 MiB (0 %) <= min 10 %
Invoking oom killer: done
Low memory! mem avail: 328 of 5875 MiB (5) % <= min 10 %, swap free: 0 of 0 MiB (0 %) <= min 10 %
Invoking oom killer: done
Low memory! mem avail: 277 of 5875 MiB (4) % <= min 10 %, swap free: 0 of 0 MiB (0 %) <= min 10 %
Invoking oom killer: done
Low memory! mem avail: 238 of 5875 MiB (4) % <= min 10 %, swap free: 0 of 0 MiB (0 %) <= min 10 %
Invoking oom killer: done
Low memory! mem avail: 201 of 5875 MiB (3) % <= min 10 %, swap free: 0 of 0 MiB (0 %) <= min 10 %
Invoking oom killer: done
Low memory! mem avail: 175 of 5875 MiB (2) % <= min 10 %, swap free: 0 of 0 MiB (0 %) <= min 10 %
Invoking oom killer: done

[706742.940955] Purging GPU memory, 1116 pages freed, 13038 pages still pinned.
[706743.032224] sysrq: SysRq : Manual OOM execution
[706743.048960] Purging GPU memory, 1116 pages freed, 13038 pages still pinned.
[706743.132372] sysrq: SysRq : Manual OOM execution
[706743.152946] Purging GPU memory, 1106 pages freed, 13038 pages still pinned.
[706743.232711] sysrq: SysRq : Manual OOM execution
[706743.253046] Purging GPU memory, 1449 pages freed, 13038 pages still pinned.
[706743.333101] sysrq: SysRq : Manual OOM execution
[706743.349036] Purging GPU memory, 1113 pages freed, 13038 pages still pinned.

ядерный может просто не срабатывать.

Плохой аргумент если честно. И в тикете никаких подробностей и анализа. Просто взяли и убрали опцию.

Просто берёт и «не срабатывает»? Если это воспроизводимо и ты считаешь что дело не в твоем коде, а в ядерном, то нужно хоть баг в ядерную багзиллу запостить.

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

Подробностей более чем достаточно - дёрганье киллера не освобождает память. Какие еще подробности нужны?

Почему не освобождает.

Потому что так и задумано, или потому что ты не за то и не там дергаешь, или потому что не хватает нужной функциональности чтобы дергать правильно?

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

Это потому что нет нужного API уровнем ниже? Тогда это feature request опять же к ядру.

Киллер дёрнуть есть один способ:

echo f > /proc/sysrq-trigger

Этот способ использовался в earlyoom, до сих пор используется в psi-monitor и low-memory-monitor. Другие способы неизвестны.

И этот способ сначала имеет такой эффект: Purging GPU memory. Убийство происходит только при быстром многократном дёргании.

Тогда это feature request опять же к ядру.

К чёрту ядро и его дубовые настройки. Юзерспейс позволяет действовать быстро и аккуратно.

Взваливание всего на ядро - отвратительная догма. ООМ киллер должен быть гибридным: ядерный защищает ядро, а юзерспейсная часть заботится об отзывчивости юзерспейса.

Взваливание всего на ядро - отвратительная догма.

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

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

Чтобы делать гибридные механизмы надо начать с того что перестать посылать друг друга к черту и начать писать дизайн-спеки и feature-request-ы которые эту гбридность будут обеспечивать.

Пока что получается не гибрид, а совершенно не связанные друг с другом реализации, без совместного плана на будущее.

Для автора systemd-юнита для какого-либо приложения например сейчас надо придумывать два механизма: первый - настройки OOMPolicy и cgroups-scope, чтобы настроить OOM Killer с точки зрения ядра, и второй - какая-то магия с KillMode и прочими костылями для реакции на сигналы от earlyoom.

При этом если по OOM Killer хотя бы понятно что это OOM Killer, и для него можно настроить какое-то специальное поведение, то earlyoom маскируется и прячется от systemd. То есть разделить нормальную остановку приложения по запросу пользователя выполненную через systemctl и остановку по early-OOM на практике нельзя.

В андроиде тоже юзерспейсный, свой.

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

Purging GPU memory

На кой черт он вообще к GPU лезет, если закончилась RAM?

люди доустанавливают

Он из коробки идет, это системное.

Я про всякие оптимизаторы, которые убивают фоновые процессы, типа CCleaner

Скажите мне, а в чем проблема настроить ядреный oom killer?

В том что его нельзя настроить на раннее реагирование. Ядерные ребята не дали ключей для этого.

В андроиде вроде он хорошо работает

В андроиде хорошо работает юзерспейсный киллер.

Пока что получается не гибрид, а совершенно не связанные друг с другом реализации, без совместного плана на будущее.

Всё так. Красиво пишешь. Это уже обсуждается, несовместимость критикуется. Добро пожаловать сюда https://pagure.io/fedora-workstation/issue/98 и возможно сюда https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YXDODS3G4YCS7MT4J2QJMJ7EXCVR7NQ2/#W73ZVOIRNNW4YVQT6FNSLI6GHUJCZSKY

а это и есть «победить на десктопе».

Пажжите, но ведь федоровцы уже собрались включить какой-то другой оом-киллер. У них будет битва?

И как ты это себе представляешь? Поттер просто сказал: мне больше нравится от фейсбука и плевать.

Как обычно.

Этот выбор выглядит прагматичным, очевидно, что реализация на C++ может быть более эффективной, чем на питоне

по-моему на опеннете кто-то из анонимов уже ошибочно писал про earlyoom и python. какая-то новая байка что ли.

Ждём юзерспейсный malloc.

сборщик мусора что ли? Ну так есть jmalloc, glibc

VM же!
(если что - это был сарказм)

про earlyoom и python. какая-то новая байка что ли.

nohang на питоне. Реализация на питоне позволила впилить больше фич за приемлемое время. https://github.com/hakavlad/nohang#some-features

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

ТС что-то там перепутал в связи с поттером

Нет.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W73ZVOIRNNW4YVQT6FNSLI6GHUJCZSKY/

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N373T3M2IWMMI46YX7Z7UMPKKSAZZRTC/

Хочется отметить, что Леннарт слегка не в теме и довольно дерзок.

принцип работы каждого из них сводится к мониторингу ресурсов и принятию решений по правилам?

Да.

тогда в чем смысл интеграции их с systemd?

В том же, в чем и смысл интеграции всего остального - systemd должен быть всепоглощающим и содержать в себе всё.

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

Нет

ну как нет. федора включает earlyoom. в этом смысле поттеринг выбирает между c и c++ (дискуссия выше). при чем тут nohang с питоном не понятно.

дополнительные настройки в юнитах

список правил должен быть в конфигурации демона. я никак что-то не пойму, в каком случае init-фрейморки должен вмешиваться. а если и собирается, то почему бы earlyoom и facebook-oom не сделать общий api по шине, чтобы они были заменяемы.

при чем тут nohang с питоном не понятно.

Это я напутал. Сказал, что earlyoom на питоне, тогда как на питоне nohang

угу. все ок.

почему бы earlyoom и facebook-oom не сделать общий api по шине, чтобы они были заменяемы

oomd - развивающийся жирный серверный монстр.

earlyoom - простой, зрелый, легкий демон, не собирающийся меняться.

Они совершенно разные. О каком общем api может идти речь?

oomd - развивающийся жирный серверный монстр.

отлично впишется парой к systemd

earlyoom - простой

а как сейчас в федоре объединяют earlyoom и systemd?

а как сейчас в федоре объединяют earlyoom и systemd?

Никак. earlyoom критикуется за то, что не поддерживает групповые убийства контрольных групп, предоставляемые юнитной опцией OOMPolicy=kill.

«If set to kill and one of the service’s processes is killed by the OOM killer the kernel is instructed to kill all remaining processes of the service, too.»

А вот теперь все ясно. Больше у меня нет вопросов