LINUX.ORG.RU

Выпуск earlyoom 1.3, процесса для раннего реагирования на нехватку памяти

 , ,


1

2

После семи месяцев разработки опубликован выпуск фонового процесса earlyoom 1.3, который периодически проверяет объем доступной памяти (MemAvailable, SwapFree) и пытается на ранней стадии отреагировать на возникновения нехватки памяти.

Если объём доступной памяти меньше заданного значения, то earlyoom принудительно (через отправку SIGTERM или SIGKILL) завершит работу процесса, наиболее активно потребляющего память (имеющего самое большое значение /proc/*/oom_score), не доводя состояние системы до очистки системных буферов и мешающего работе своппинга (обработчик OOM (Out Of Memory) в ядре срабатывает когда состояние нехватки памяти уже достигло критичных значений и обычно к этому моменту система уже не реагирует на действия пользователя).

Earlyoom поддерживает отправку уведомлений о принудительно завершённых процессах на рабочий стол (с помощью notify-send), а также предоставляет возможность определения правил, в которых при помощи регулярных выражений можно задать имена процессов, завершение которых предпочтительно (опция "--prefer") или остановки которых стоит избегать (опция "--avoid").

Основные изменения в новом выпуске:

  • Реализовано ожидание завершения процесса после отправки ему сигнала. Это устраняет проблему, заключающуюся в том, что earlyoom иногда убивает более одного процесса, когда одного будет достаточно;
  • Добавлен вспомогательный скрипт (notify_all_users.py) для уведомления всех залогиненых пользователей о завершении процессов через уведомления notify-send;
  • Исправлено некорректное отображение некоторых имен процессов, содержащих UTF-8 символы;
  • Принят кодекс поведения (Contributor Covenant Code of Conduct).

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

★★★

Проверено: jollheef ()
Последнее исправление: Deleted (всего исправлений: 2)

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

У ООМа на уровне ядра нет разделения на десктопы и все остальное. Он там один на все случаи жизни. И он либо работает везде, либо не работает нигде. Поэтому странно, что ты выделяешь юзкейс десктопов отдельно.

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

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

Ну потому что критерии слишком разные. Не натягивается всё на всё. Ничего не поделаешь.

fornlr ★★★★★
()

Теперь полторы строчки на баше гордо именуют процессом ?

И да, oom score считается через жопу.

Ага, mysqld с потреблением гигабайта оперативы vs 100 инстансов php-fpm с потреблением 20 Мб\каждый - зачем заморачиваться с полтосом мелких ненужных ? Лучше кильнем сразу mysqld и положим ресурс. Лол.

windows10 ★★★★★
()

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

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

чёнить типа такого

vm.overcommit_ratio = 100
vm.overcommit_memory = 2
Или как ?
Ну и соответсвенно overcommit_ratio можно повышать, если уж браузеру 100 маловато.

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

Там столько нюансов

там буквально 3 параметра про память если говорить про setrlimit(3).

С cgroups примерно тоже самое.

sergej ★★★★★
()

Почему бы просто не занять заранее 2гб памяти, а при нехватке просто её освободить?

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

А что это даст ?

Если есть ЧТО освобождать - значит свободная память есть, и с ООМ тоже проблем не будет.

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

Он виснет из-за отсутствия свопа.

У меня и со свопом зависал. И не только у меня.

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

Так многое валится с нехваткой памяти когда её полно, потому что virt многократно превышает res.

Приходится ставить что-то вроде vm.overcommit_ratio = 500.

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

Ага, со свопом у меня вис на несколько часов. Без свопа хотя бы за минут 20 оживает. Зато работает от кофеварки до суперкластера. Так и живем.

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

Послушай хватит фигню говорить, реально надоело.

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

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

К примеру, я видел код, формирующий строковые дескрипторы USB, там был strdup() (в проекте всего 512Кб памяти, часть выделено для кучи), а вот free() - не было. И как бы всё работает, в большинстве случаев, и проявляется только если устройство активно, без перетыкания, будет ренумерироваться. Например, перезагружать комп, не отключая устройство. Но раньше ты его выткнешь, чем нарвёшься на проблему.

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

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

Если только на этом десктопе нет браузеров или проектов, под компиляцию которых требуется > 8 ГБайт ОЗУ.

А так как у меня 8 ГБ из-за нерабочей двухканалки, то приходится наблюдать свопинг и нагрузку. Впрочем, заполнить можно и 16, 32.

А без свопа обычно почти сразу приходит ООМ.

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

Я не знаю, что там работает, за >10 лет у меня этот OOM НИ РАЗУ нормально не отработал, что со свопом, что без. Система просто встаёт колом и всё, туши свет, максимум может выручить sysrq, и то не всегда. Может его надо настраивать, но какого лешего?

false ★★★★★
()

Кстати, чё-то припоминаю, что таких проектов было сразу несколько. Какой из них лучше?

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

Какой из них лучше?

Используй earlyoom, если не знаешь какой выбрать. oomd пока неюзабелен. nohang не до конца стабилизирован, хотя и более фичаст.

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

А что такое лимиты? Там столько нюансов, что так просто не получится это легко описать, и зареализовать.

Легче, чем написать целый костыль из оппоста.
Там нет никакого rocket science, см. вот эту тему, например: запуск в cgroup

Лимитированный процесс не в силах залочить машину.
Он быстро будет задушен memory контроллером, и пойдёт очень печально свопиться в индивидуальном порядке, с самым низшим blkio, которым ты его наградишь в группе.
Не надо никого убивать раньше времени от страха дедлока.

memhog-бомбы не просто не работают, но могут быть практически незаметны с лимитами.

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

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

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

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

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

браузеры есть. не возникает проблем. естессна, отключены все баннеры и прочее такое.

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

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

С учётом того, что жалобы на зависание устройства не было и всё решается «перетыком»... Возможное решение проблемы в таком случае: ну и х..н с ним! Софт/железо без багов выпустить нереально, что бы оно ещё и стоило адекватных денег (иногда такую фиерию писать приходится, что бы хоть как-то нивелировать какой-то хардварный баг или «особенность»).

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

Плюс сложность растёт. Лет 20 назад embedded был синонимом PIC/AVR и ассемблера. Сейчас уже ресурсов больше, чем у моего первого компа и с ЯП высокого уровня. И многое просто в голове уложить не получится. Плотность косяков, как софтовых, так и аппаратных, тоже увеличивается.

Поэтому иногда просто... ну виснет устройство раз в 1000 подключений, ну и ладно, дольше/дороже разбираться. Большинство этого просто не заметит, как и утечку, описанную мною выше (да просто раньше ты устройство отключишь и всё вернётся на круги своя).

h4tr3d ★★★★★
()

Судя по описанию при срабатывании башскрипта с мини форкбомбой эта штука сначала прибьет всё вокруг а потом всё равно подвиснет.

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

Судя по описанию при срабатывании башскрипта с мини форкбомбой эта штука сначала прибьет всё вокруг а потом всё равно подвиснет.

На это случай есть https://github.com/hakavlad/fork-bomb-killer - можете комбинировать это с предотвратителями ООМ.

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

да всё можно. и нормально пилится. и хардварные баги правятся. на то она и разработка. а иначе это просто говнодевайс. я это не просто так говорю, я работала в разработке железа. да и не только железо. серверный софт, который должен гарантированно работать 24/7 точно так же пишется. если сбой софта приносит миллионные убыли для бизнеса, то всё нормально пишут и всё работает. и тем более если от какого-то девайса зависит жизнь людей - это вообще на сто раз всё проверяться должно. криворукость тут не отмазка.

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

Форкбомба это условный пример.

Для других случаев, если есть сервер с предсказуемым набором процессов, можно тонко регулировать приоритеты процессов через сопоставление различных их свойств (name, cgroup, cmdline etc) с регулярками и прибавлением/убавлением величины badness.

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

Переменная установлена. Сервер уведомлений notify-osd тоже (или какой нужен?) Сообщения от root notify-send передаются юзеру в GUI... но nohang молчит... мало того что молчит, но при запуске https://github.com/hakavlad/nohang-extra/blob/master/oom-trigger система становится колом и ничего не происходит - помогает только alt-sysrq-b

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

https://github.com/hakavlad/nohang/issues/32 Проблема зарегистрирована. Пожалуйста, пройдите туда и выйдите на связь, если Вас это не затруднит.

На самом деле разгадка может быть проста: low memory warnings при быстром падении уровня доступной памяти может быть причиной проблем: демон однопоточен и останавливается при порождении уведомлениия. - Это может занимать несколько секунд если своп на HDD. - За это время может прийти OOM. Хотелось бы увидеть аутпут с со всеми включенными флагами verbosity.

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

notify-osd тоже (или какой нужен?)

Включение этой опции требует наличия notify-send в системе. В Debian/Ubuntu это обеспечивается установкой пакета libnotify-bin. В Fedora и Arch Linux - пакет libnotify. Также требуется наличие сервера уведомлений. При запуске nohang от рута уведомления рассылаются всем залогиненным пользователям. See also wiki.archlinux.org/index.php/Desktop_notifications Valid values are True and False.

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

1. Используете ли релизную версию 0.1 или последнюю v0.1-349. 2. Запускаете ли от рута. 3. Покажите output с включенными verbosity опциями. Спасибо.

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

github затруднит

возможно ли изменив опцию mem_min_warnings гарантировано спровоцировать отправку уведомления после перезапуска nohang?

при включении всех флагов происходит следующее: service nohang status ● nohang.service - Highly configurable OOM prevention daemon Loaded: loaded (/lib/systemd/system/nohang.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Fri 2019-06-07 14:53:15 EEST; 63ms ago Docs: man:nohang(1) https://github.com/hakavlad/nohang Process: 23874 ExecStart=/usr/sbin/nohang --config /etc/nohang/nohang.conf (code=exited, status=1/FAILURE) Main PID: 23874 (code=exited, status=1/FAILURE)

чер 07 14:53:15 nonamehost systemd[1]: nohang.service: Failed with result 'exit-code'.

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

возможно ли изменив опцию mem_min_warnings гарантировано спровоцировать отправку уведомления после перезапуска nohang?

mem_min_warnings = 99 %

swap_min_warnings = 99 %

Тогда будет периодичекси давать уведомления об уровне памяти начиная со старта.

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

по verbosity - неудача, ранее показал результат.

Показали статус в системд, но не аутпут самого демона.

Тогда так: покажите вывод sudo journalctl -eu nohang (там вывод демона самого должен быть).

Должен стартовать так (в терминале если):

$ sudo nohang Config: /etc/nohang/nohang.conf Monitoring has started!

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

эта ошибка точно влияет на нотифи? она проявляется только при verbose. без подробного вывода служба стартует...

fidaj
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.