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)
Ответ на: комментарий от hakavlad

если есть сервер с предсказуемым набором процессов

То можно настроить лимииты

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

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

она проявляется при print_sleep_periods = True. Пожалуйста, выключите печать периодов сна и повторите попытку. И запускайте oom-trigger на мылых оборотах, например same=9, urandom=0.

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

SwapFree: 20212 M, 100.0 %

А уведомление покажется когда свободного свопа меньше 99%. Попробуйте с отмонтированным свопом, или заполните своп частично. Уведомление покажется когда оба порога превышены (MemAvailable < 99% and SwapFree < 99% в соответствии с настройками)

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

ура! при значении 100% наконец-то всплыло сообщение :))) - значит что-то шевелится. буду еще пробовать что бы что-то капризное начало убивать. спасибо!

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

Пару вопросов и замечаний. При обновлении кода приходится постоянно переписывать собственный конфиг, который перезатирается командами make install - возможно ли сделать команду make upgrade которая учитывает наличие измененного конфига? Это же касается и команды make uninstall - она удалает отличный от дефолтного конфиг.

Как учитываются пределы при отображении уведомлений от параметров mem_min_warnings swap_min_warnings zram_max_warnings? Такое впечатление что mem_min_warnings & swap_min_warnings учитываются вместе, zram_max_warnings не учитывается вовсе, даже если установлено ignore_zram = False - возможно ли изменить логику поведения отображений по любому превышению значений и если установлено ignore_zram = False - то отображать в уведомлении информацию о zram тоже; и если «нет» - то почему?

P.S. PSI - зло - не пытайтесь его использовать - вешает систему: https://pastebin.com/xxWDzzYT не знаю, возможно из-за планировщика MuQSS...

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

запустил с рекомендациями... oom-triger выжрал всю оперативу плюс свап - потом начал побайтово добивать, но его так киллер и не убил - я прервал задачу - это нормальное поведение nohang?

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

возможно ли сделать команду make upgrade которая учитывает наличие измененного конфига?

Можно, но не сейчас.

Как учитываются пределы при отображении уведомлений от параметров mem_min_warnings swap_min_warnings zram_max_warnings? Такое впечатление что mem_min_warnings & swap_min_warnings учитываются вместе

Все верно, все как и с порогами для отправки сигналов: реакциия если превышены оба порога одновременно:

if (mem_available <= mem_min_warnings_kb and swap_free <= swap_min_warnings_kb or mem_used_zram >= zram_max_warnings_kb):

zram_max_warnings не учитывается вовсе, даже если установлено ignore_zram = False

Уведомления о переполнении zram работают. Проблема в отсутствии документации. Проблема в понимании того, какую именно zram-метрику измеряет демон. Это тема отдельной статьи. Пока же смотрите скриншоты: https://i.imgur.com/0kY1ZsP.png и https://i.imgur.com/QUSTLs7.png - это уведомление о переполнении zram. Другое дело, что демон сломан и не реагирует сейчас адекватно на уровни PSI и zram.

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

Это плохая идея. Можно достичь нужного эффекта манипулируя двумя этими параметрами. Чтоб была реакция на 1 параметр, можете значение второго установить на уровень 100%. См https://github.com/rfjakob/earlyoom/issues/55

и если установлено ignore_zram = False - то отображать в уведомлении информацию о zram тоже; и если «нет» - то почему?

Уведомления о переполнении zram работают, см выше

PSI - зло - не пытайтесь его использовать - вешает систему

PSI сам по себе - это новая ядерная метрика. Сейчас реакция на PSI в nohang сломана (https://github.com/hakavlad/nohang/issues/31). Применение PSI мало протестировно. Мое мнеие таково: в норме при работе со свопом значение PSI могут достигать больших значений. Это может дыть нормально, если длится не очень долго. Длительные (сейчас в демоне дефолт - 30 сек) превышения PSI нужно обрабатывать. Сам по себе PSI не может вешать систему.

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

его так киллер и не убил - я прервал задачу - это нормальное поведение nohang?

Нет. Включите печать всех результатов проверки памяти (print_mem_check_results = True, min_mem_report_interval = 0) и повторите попытку. Каков вывод на уровне памяти, на котором должна быть реакция?

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

говорю же - сожрало весь zram и почти весь swap

Может в этом и разгадка. Если порог для свопа не превышен, то реакции не будет. А реакция на zram сейчас сломана. Вот пример лога, где nohang облажался: http://okturing.com/src/6307/body

Пожалуйста, отключите zram и PSI в настройках для временного решения проблемы. Прогресс решения проблемы можете отслеживать здесь: https://github.com/hakavlad/nohang/issues/31

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

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

круто! спасибо!

кажись еще какой-то баг выполз - сервис стартует и падает...

psi_avg_warnings not in config
ааа - это мой конфиг, сорри

только про PSI я подразумевал о ядерном баге...

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

Ключевые слова: многомилионные убытки, жизнь.

К примеру, MTшные SoC, на которых львиная доля бюджетных телефонов собрана, косяков уйма. Зато дёшево. Cypress FX3 - хороший чип, но тоже дёгодь имеется. Да под любую железку это продолжать можно. Что-то в софте обойти можно, что-то не использовать под задачу. Но, сама фраза «обойти в софте» уже подразумевает подход аналогичный утилите из треда.

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

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

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

неправильно править косяки железа софтом

Другого пути нет, если мы уже имеем косячное железо.

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

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

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

Часто маркет устроен так, что клиенту, если хоть как-то жить можно, лучше иметь то, что есть, но сейчас, чем идеал, но через N месяцев/лет/etc.

Т.е. клиент выбирает такой подход. К сожалению, трудоёмкость разработки во всех сферах, что железа, что софта растёт, судя по всему, экспоненциально. И вылизать продукт до зеркального блеска не хватит ни средств, ни времени.

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.