LINUX.ORG.RU

Выпуск earlyoom 1.2

 , ,


1

3

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

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

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

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

  • Внедрение адаптивного времени сна (адаптивная частота проверки уровня доступной памяти) для снижения нагрузки на процессор: чем меньше доступной памяти осталось, тем чаще проверяется объем доступной памяти (один раз в секунду если памяти достаточно и чаще по мере ее уменьшения)
  • Удалена опция -k для вызова ядерного oom-killer'a (ее использование давало непредсказуемые результаты; теперь эта опция игнорируется для совместимости)
  • Исправлен баг с некорректным поведением после монтирования своп-раздела, если earlyoom уже был запущен
  • Реализовать ступенчатое завершение процессов: сначала происходит попытка корректного завершения процесса путем отправки ему сигнала SIGTERM, и только в случае отсутствия реакции на SIGTERM и при дальнейшем уменьшении доступной памяти происходит отправка SIGKILL процессу с наибольшим oom_score.

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



Проверено: jollheef ()

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

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

Но с вероятностью примерно 99% в нём просто утечка памяти или неправильно прописанные настройки. Нормальные люди не будут добровольно и осознанно запускать процесс, который гарантированно не влезет в оперативку

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

сама логика «убивать самый жирный процесс» немного идиотична, не находите?

Убивается не просто самый жирный. На oom_score влияет также время жизни процесса. Также процессы рута имеют меньший oom_score. Также жирность регулируется через правку oom_adj.

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

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

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

а то получается, играю я в игру, и тут приходит оом-киллер и убивает её, а последнее сохранение было 20 минут назад, вот я счастлив буду

или ещё хлеще - процесс убивается по время записи сохранения, и сохранёнка битая

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

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

Это не относится к людям, имеющим 4 гига оперативы и меньше. У меня 6 гиг опепативы, и все 6 может съесть один хром или две-три лисы.

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

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

Реализация этой фичи планируется в https://github.com/hakavlad/nohang, всему свое время

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

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

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

может ли иметь смысл не прибивание а остановка ряда процессов?

Да, может. Есть сигналы SIGSTOP и SIGCONT, а также программы для реализации всплывающих диалогов. Всё это теоретически реализуемо.

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

1) Убийство мелких процессов не даст профита. Допустим, некий процесс выжрал 10 ГБ, а ещё десяток по 100 МБ. Ты их убьёшь и освободишь 1 ГБ. Но жирный процесс выжрет и его и всё равно его придётся убить, потому что больше некого. В свою очередь, если убить жирный процесс, то вряд ли процессы на 100 МБ потом внезапно растолстеют и опять выжрут всю ОЗУ. То есть логика в том, что если убивать не самый жирный процесс, то это тупо даст немного времени, но ничего не изменит глобально, потому что прожорливость процесса обычно имеет прямую корреляцию с уже занятой им памятью. OOM же руководствуется логикой, что нужно убивать минимальное количество процессов.

2) Ядерный OOM учитывает ещё время жизни процесса. По возможности он постарается убить наиболее свежий процесс. Почему? Потому что чем меньше процесс отработал времени, тем безболезненнее должен быть его перезапуск. Допустим, ты запустил две числодробилки. Одна отработала час, другая 5 минут. Если убить первую, то будет потерян час работы, если вторую, то 5 минут. Выбор очевиден. То же касается и приложений, где инфу создаёт сам юзер. Лучше потерять 5 минут работы в текстовом редакторе, чем час.

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

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

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

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

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

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

программа сама создаёт и активирует дополнительный файл подкачки

Swapspace — консольная утилита, работающая в фоновом режиме (демон), предназначенная для динамического управления подкачкой (динамический менеджер подкачки / a dynamic swap manager). Создана в рамках проекта Software Industry Promotion Agency (SIPA), автор Jeroen Т. Vermeulen.

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

Alt-SysRq-F

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

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

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

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

Не всегда срабатывает

Лолвут? Там у тебя аппаратные зависоны похоже, а не oom.

не всегда включено из коробки

Ну так включи.

отправляет сразу SIGKILL

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

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

Лолвут? Там у тебя аппаратные зависоны похоже, а не oom.

Ты не прав. Magic SysRq enabled by boot cmdline on my Debian. Alt+SysRq+F usualy not works if pressed once. It works only by fast repeated pressing, sometimes with the side effects of killing Xorg. https://github.com/rfjakob/earlyoom/issues/80

anonymous ()

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

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

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

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

Кто это юзает на сервах и какое у них для этого обоснование?

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

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

WitcherGeralt ()