LINUX.ORG.RU

Второй релиз юзерспейсного OOM киллера oomd 0.2.0

 ,


1

1

Второй релиз юзерспейсного OOM киллера oomd 0.2.0, лицензированного под GPL-2.0 и написанного на C++.

Релиз 0.2.0 включает в себя множество обновлений и перестановок файлов, чтобы упростить пакет oomd для дистрибутивов Linux: https://github.com/facebookincubator/oomd/releases/tag/v0.2.0

RPM для только что выпущенного oomd v0.2.0 доступны в этом репозитории COPR: https://copr.fedorainfracloud.org/coprs/filbranden/oomd/

oomd ориентирован на высоконагруженные сервера и для работы требует поддержки PSI и cgroup2.

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

Я думаю, было бы неплохо, если бы у нас был способ заставить пользователей Fedora принимать участие в экспериментах, а затем случайным образом давать им такие вещи, как nohang и earlyoom, oomd и монитор с низким объемом памяти. Нет документации, нет предупреждения, ничего. Они просто получают один из них. Как будто это их установка по умолчанию. И посмотреть, что взрывается, или нет, какие жалобы у них есть, или нет. Если они явно устанавливают что-то, а не случайно, они в конечном итоге оказываются смещенными, что фактически загрязняет данные. Просто мысль.

https://pagure.io/fedora-workstation/issue/98#comment-597005

Теперь прошу юзеров Федоры описать свой разрыв.

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

То, что в условиях десктопа его не надо предотвращать. За всю свою жизнь видел его ровно 2 раза: когда гонял специальный самопальный тест по перегрузке памяти. Что то в духе «постепенно забить 64 гб памяти мусором, прочитывая всё на каждом цикле» на ноуте с 8Гб оперативки и ssd-свопом. Собственно когда воп кончился, oom и пришёл.

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

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

в условиях десктопа его не надо предотвращать

Конечно надо. Не у всех 64 ГБ оперативы. Многие еще продолжают жить с ноутбуками с 2 - 4 ГБ. Потеря отдного процесса - это лучше, чем зависание с последующих хард ребутом (неподготовленные пользователи делают именно последнее).

и ssd-свопом

HDD продолжают выпускаться. Есть причины, по котрым люди до сих пор предпочитют именно их.

с нехваткой памяти справляется своп.

Не у всех есть возможность отрастить большой и быстрый своп.

быстро, медленно, не важно

Ну это вообще пушка. Не важно, будет у тебя комп висеть минуту или час.

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

какие-то надуманные проблемы

на работе несколько десятков десктопов с ОЗУ 1 Гб и свопом на НЖМД... и никаких ужасов... ни зависаний, ни хардресетов...

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

Ну и чем ваш костыль лучше костыля cgroups?

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

Например, если хотите защитить систему от переполнения памяти путем использования earlyoom - достаточно его просто установить, и он будет работать достаточно хорошо, реагируя, если SwapFree < 10% & MemAvailable < 10% (пороги легко изменить через конфиг). Эти пороги будут работать на любой системе с любым размером памяти.

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

Далее. При ООМ внутри сигруппы (если группа упрется в лимит memory.max) в ней произойдет вызов OOMK и жирный процесс будет убит через SIGKILL: это еще один минус - невозможность кастомизации корректирующего действия (в earlyoom и nohang процесс сначала получит SIGTERM для возможности более корректного завершения).

Далее, настройка сигруп не позволяет (пока не позволяет, но Лёня обдумывает) реагировать на превышение в системе заданных уровней PSI memory pressure: если в системе интенствный swapping/thrashing/конкуренция за память, да такая, что рабочий стол замерз (это может произойти и при большом свободнос свопе) - сигруппы тут также бессильны.

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

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

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

убивает на сервере софт ради которого сервер покупается?:)

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

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

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

Сторожевой таймер, во встраиваемых системах стоит по дефолту. Его надо только включить и периодически сбрасывать. Если сбрасывать уже некому то reboot.

Походу в серверах надо делать тоже самое (а может и есть)

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

Не важно, будет у тебя комп висеть минуту или час.

Что то подвисло? Давайте кто то решит, какой процесс убить! Великолепное решение вопроса. Давайте что нибудь сломаем ещё до того, как возникнет проблема.

Не у всех 64 ГБ оперативы.

А мне казалось, что уже каждый аноним на ЛОРе в курсе, что у меня RPi3 в качестве основного компа. Это 942М доступной памяти, из которых только 500М может быть выделено одному процессу в нормальных условиях. Если остановить всё остальное, включая Х и kdm, то 750М.

HDD продолжают выпускаться

...и именно такой, 2,5", 5400RPM, на контроллере юсб2, стоял у меня в качестве свопа полтора года до этого августа, когда я поставил ssd.

И угадайте, сколько раз ко мне приходил oom?

А уж для самых тяжёлых случаев, почему юзерспейсный oom? Почему не передавать SIGSTOP и не вызывать человека, чтобы он разобрался? А уж темболее, зачем пихать технологию для 0,1% случаев в базовую поставку?

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

Сраный фокс почти идеальный кандидат для работы в свопе. В случае с ssd свопом я вообще не замечаю разницы, в опере он работает или уже 150% отсвопил. Так что да, вы с ним что то упоротое делаете.

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

Почему не передавать SIGSTOP и не вызывать человека, чтобы он разобрался?

Я рассматриваю это. Я еще поиграю с этим. У SIGSTOP естиь минус - некоторые процессы после него некорректно просыпаются.

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

Почему не передавать SIGSTOP и не вызывать человека, чтобы он разобрался?

Это ж продумать алгоритм надо. Какие именно процессы замораживать? Как выбрать те, которые заморозить? Как сообщить юзеру, что такие-то процессы получили SIGSTOP? Это сложнее в реализации, чем просто SIGTERM/SIGKILL.

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

Что то подвисло? Давайте кто то решит, какой процесс убить! Великолепное решение вопроса. Давайте что нибудь сломаем ещё до того, как возникнет проблема.

Определенные уровни памяти - это уже проблема. Если на сервере MemAvailable+SwapFree < 10 MiB - вы, вероятно, не сможете даже залогинится. Так что это не ломание системы, а ее лечение.

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

Ни разу, ведь я использую nohang. До того бывали случаи периодически, если не следил за памятью через монитор. И да, бывали жесткиt ресеты, до того, как узнал про sysrq.

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

Риску подвержены все, но вы ради любопытства проведите опрос, как много людей встречаются с проблемой и как много из них считают допустимым решать её через oom-killer

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

как много из них считают допустимым решать её через oom-killer

Оно и так по дефолту через oom-killer решается. Жаль, что не всегда, иногда бесконечно долго приходится ждать неотвечающую замерзшую нерабочую систему.

hakavlad ()