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/

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

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

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

Можно конечно спихнуть на «не хватает ОЗУ - добавляй, приложения текут - чини»

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

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

Ну так а я о чём?

Можно конечно спихнуть на «не хватает ОЗУ - добавляй, приложения текут - чини»

Фанатичные обезьянки эту мантру хорошо выучили. «Ядро Linux пишут святые, они не могут ошибаться, это твоё приложение кривое и оперативки у тебя мало!»

mord0d ()

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

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

хорошо зарекомендовал себя при промышленных нагрузках

OOM Killer в GNU/Linux приходит настолько редко, что он уже давно перекочевал в разряд мифов.

Приходит, еще как приходит.

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

Приходит, еще как приходит.

Это сабж приходит, а я про тот, что в ядре.

При чем тут ядро?

Суть моей мысли кратко для отсталых: сабж пришлось написать потому, что от ядрёного толку нет.

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

Чем это лучше earlyoom?

earlyoom примитивный как палка. Реагирует только на низкий уровень доступной памяти (MemAvailable & SwapFree). И посылает только SIGTERM/SIGKILL в качестве корректирующего действия.

oomd позволяет реагировать на разные нагрузки (с использованием PSI для детекции) разным образом. Для oomd можно писать весьма гибкие плагины. ИМХО oomd подходит как раз для таких контор как фейсбук, для крупных датацентров. Для простых домрхозяек он избыточен.

Если вам просто нужно средство для ранней реакции на низкий уровень памяти - используйте earlyoom. Он прост, легок и стабилен.

Если вас не устраивает примитивность earlyoom, то лучшим выбором будет nohang - https://github.com/hakavlad/nohang. Он позволяет весьма тонко настроить выбор жертвы, выводит подробную информацию о жертве и о состоянии процессов перед корректирующими действиями, а также позволяет мониторить через PSI состояние заданной сигруппы. Скоро будет релиз nohang 0.2. hakavlad/nohang github.com

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

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

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

«Ядро Linux пишут святые, они не могут ошибаться, это твоё приложение кривое и оперативки у тебя мало!»

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

AS ★★★★★ ()

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

Deleted ()

Если бы вместо kill -9 оно посылало сигнал 19 или как то так раздавало приоритеты и лимиты памяти, чтобы всё оседало в своп, работало в приоретете idle и не просыпалось пока система не разгрузитя....

А так это просто ещё один кусок мусора который вероятно через 5 лет придётся вычищать из десктопных дистрибутивов. И какой нибудь системд ещё и будет сопротивляться его выкидыванию.

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

божечки мои ни разу не приходил этот призрак

а я помню он вечно пришибал всякие бесполезные процессы навроде bash, rsyslogd и всякие такие. понятно что на базу, которая сожрала 50Гб как ен в себя ему было пофиг.

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

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

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

я не знаю, что такой «шарики с физикой», но начнись у тебя выгрузка в своп и затупи твои диски, никуда бы ты не зашел. твой ssh клиент отвалился бы по таймауту.

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

Но не отвалился же )) я даже pid процесса в top глянул что бы его хлопнуть. Всё неистово тупило, но кое как хлопнул процесс, а память в своп уходила потому что я логи писал в память вот и вышло через несколько часов ~20 гигов уведомлений о том что расчёт коллизий шариков провалился и он улетел в никуда

Deleted ()

subj - конечно, linux-way подпорка. принцип базара. все быстро подпиливают и подпирают что-то свое. после того, как появились cgroups было бы логично переписать ядерный OOM. да и умная конфигурация налету логичная вещь.

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

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

Проблемы индейцев шерифа не волнуют. Юзерспейс сам должен решать проблему нехватки памяти в юзерспейсе. По крайней мере так думают разрабы ядра.

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

Можно конечно спихнуть на «не хватает ОЗУ - добавляй, приложения текут - чини»

Проблема плохой обработки OOM и проблема нехватки памяти - это две разные проблемы. Система с большим объемом ОЗУ тоже может встать раком, если приложения потекут. С другой сторонй, система с хорошо настроенным обработчиком нехватки памяти не будет фризиться даже при протекающих приложениях (протекающие будут корректно и вовремя завершаться).

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

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

Ну резет - это вообще дикость. Попробуйте хотя бы earlyoom. Он легко ставиться на любую систему и неплохо работает из коробки.

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

vm.min_free_kbytes = 524288

Трёхсот тысяч вполне достаточно. Большое значение vm.min_free_kbytes уменьшает объем доступной памяти. Не ставьте большое значение на системах с небольшим объемом ОЗУ.

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

Не сталкиваюсь, так что мне не нужно. А про TLP что скажешь?

Питаюсь от сети и не нуждяюсь в TLP. Впрочем, после последнего акта удвоения объема оперативы, не нуждаюсь и в юзерспейсных киллерах (почти).

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

я лично наблюдал как ядерный бил по башке много и часто

Лорчую адеквата. Хотите увидеть работу OOMK? Установите vm.overcommit_memory в единицу и выполните команду tail /dev/zero. Доступная память быстро исчерпается и придет киллер. Предварительно можете отключить своп чтоб ускорить процесс. Еще более надежная команда для вызова OOMK: while true; do setsid tail /dev/zero; done.

hakavlad ()