Больше костылей богу костылей!

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

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

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

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

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

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

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

Facebook

А разве Facebook нужен?

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

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

У меня он из коробки тоже не работает. Спасает такой конфиг:

vm.oom_kill_allocating_task = 1
vm.swappiness = 40
vm.min_free_kbytes = 524288

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

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

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

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

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

А разве Facebook нужен?

Ненужен, но пусть будет в качестве разрабов и тестеров.

А кто и что? Кто виновник всех бед :)

Ты никогда не видел ПАКи?

Разработка Facebook

и сразу нахер.

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

Кто-нибудь уже опробовал?

Пытался, но не осилил установку.

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

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

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

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

Чем это лучше 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

Это такой же стрёмный костыль как и TLP https://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-management.html

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

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

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

И я про тот что в ядре. Места знать надо!

Места знать надо!

То есть я должен сходить и притащить OOM Killer за уши? И нафиг он такой нужен?

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

А как же HogKiller?

5 раз в день редко?

зимой я лично наблюдал

Ты его не спутал с Дедом Морозом (или Санта Клаусом, если будет угодно)?

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

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

Уже часть systemd, или ещё нет? :-)

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

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

Когда ядро течет, его нужно убивать. Такой вот линукс.

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

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

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

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

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

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

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

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

так я о том и говорю. это ничего не доказывает вообще. задача у тебя была такая. повезло и только.

Иногда хотелось бы, что бы приходил чаще :-\

Больше костылей богу костылей!

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

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

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

Поставь zswap и перестань страдать.

А кто и что? Кто виновник всех бед :)

Поттеринг и systemd!

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

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

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

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

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

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

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

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

vm.min_free_kbytes = 524288

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

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

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

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

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