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

Не понимаю

IQ < 100?

Выключите оверкоммит

Яйца бы поотрезать таким советчикам

Память нужно сжимать архиватором Бабушкина, а своп отключить.

Всегду нужны регионы непрерывной настоящей памяти для dma, например. Может ещё что-то не сжать.

oomd ориентирован на высоконагруженные сервера

На федоре, да?

А есть гайд? Я бы попробовал.

https://www.opennet.ru/tips/3116_oomkill_memory_earlyoom_nohang_oomd.shtml

- сравнение киллеров. Выбери понравившийся. Гайды лежат в ридми на гитхабах проектов.

На федоре, да?

На RHEL 8 завезут скоро, наверно. А далее и на Debian & Ubuntu..

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

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

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

Если я не написал свой oom killer, я не могу считаться хорошим разработчиком?

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

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

Нет, не позволяет.

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

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

и ssd-свопом

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

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

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

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

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

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

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

Статья со сравнением аналогов: https://www.opennet.ru/tips/3116_oomkill_memory_earlyoom_nohang_oomd.shtml

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

Двачую. У меня вообще на работе компы с 32 МБ оперативой. Зависаний нет, компы летают как мухи, брат жив.

У меня вообще на работе компы с 32 МБ оперативой

Это не ты с братом?

https://i0.wp.com/bazara0.com/wp-content/uploads/2016/06/electronics_graveyar...

С таким же успехом можно и юзерспейсными киллерами обмазаться, и сказать, что проблемы нет.

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

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

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

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

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

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

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

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

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

Спасибо за исчерпывающий ответ!

национальная

русскими неосиляторами

Проверяешь, с какого комментария тред будет считаться нацполом?

Чорд. Надеялся, скор снимут, не хотел третью звезду.

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

Не эти то я знаю, я так понял ты говоришь что и без них можно настроить

Если сервер покупался под этот софт, на нём будет достаточно памяти, и никто не будет убит.

Это же, вроде, единственная, которая только на сервере. Прочие похожие и на десктопе. Хотя, эта с десктопа может сгонять юзера, это же еще круче.

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

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

Думаю открыть компанию Red Hang и продавать услуги по настройке OOM киллеров.

Еще можно winlogon.exe суспендить, дорого. Сейчас на LOR как-то много таких, которым понравится возможность заплатить, чтобы им кто-нибудь winlogon засуспендил.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

для 0,1% случаев

Для 100% случаев. Ядро пока не пофикшено, потенциально все подвержены риску.

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

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

Ничего упоротого не делаю, открываю странички, чреди которых втречаются жырные и привет.

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

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

Для 100% случаев.

Сколько раз в год к тебе приходил оомкиллер?

Так он не приходит. Всё висит.

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

report back on how they work for you!

1. They kill all the session

2. They uses 7% CPU on my VM.

https://imgur.com/a/FSOtqPm

Resume: they are not for desktop. Don't advise it to use on desktop. Use earlyoom or nohang on desktop instead of oomd. - https://github.com/facebookincubator/oomd/issues/90#issuecomment-530836227

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

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

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

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

юзерспейсного OOM киллера
oomd ориентирован на высоконагруженные сервера

))))

что-то тут не так, чую подвох,но где... -_-

но штатный oom до последнего даёт возмможность системе разрулить ситуацию свопом и другими механизмами.

Ни разу, ведь я использую nohang.

А до этого?