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 ()
Последнее исправление: Deleted (всего исправлений: 1)

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

Не совсем по теме — а какой процесс при разработке микросхем должен пыхтеть неделю (видимо, без участия человека), да ещё так, чтобы до OOM-а доиграться? Что-то типа автоматической разводки проводников?

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

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

ncrmnt ★★★★★
()

Да браузер съедает большое количество памяти и даже был какой то глюк, что лик памяти приводил к Out of memory, но текла память не в Firefox, а в дочернем процессе Web Content, что ядро успешно убивало.

Правда после Out of memory почему то глючит ядро, приходилось перезагружаться.

Firefox обновили, проблема ушла, но вообще я очень мучился. Автору спасибо за приложение. Буде знать

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

А что админу то остаётся делать? Исходники он исправить не всегда может. Так что только убивать и пепезапускать. Логично автоматизировать, чтобы минимизировать время простоя.

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

по-человечески можно было бы сделать так: вывести предупреждение

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

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

раз самый нормальный вариант — если что-то пошло не так, вызвать штатные средства очистки

Штатные средства могут вообще не срабатывать - https://github.com/rfjakob/earlyoom/issues/80

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

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

Нет, не слишком. Потребление ресурсов - но нулям: считывание /proc/meminfo раз в секунду.

How much memory does earlyoom use?

About 2 MiB (VmRSS), though only 220 kiB is private memory (RssAnon). The rest is the libc library (RssFile) that is shared with other processes.

ALSO

in recent kernels (tested on 4.0.5), triggering the kernel oom killer manually may not work at all. That is, it may only free some graphics memory (that will be allocated immediately again) and not actually kill any process. - see https://github.com/rfjakob/earlyoom

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

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

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

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

Прикол в том что в Винде (как минимум начиная с 8-ки) такое есть штантно из коробки. Появляется окошечко с приблизительно такой надписью. «В системе исчерпана память, сохраните данные приложения %appName% во избежания их потери» - или что-то типа того.

И в диалоге кроме текста и кнопочки «ок» ничего нет - т.е. это просто рекомендация и предупреждения если памяти станет еще меньше то вероятным кандидатом на убийство послужит %appName%.

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

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

ну проще просто убить именно то что жрет ОЗУ, а не что-то фоновое, потому что это привнесет неопределенность в работе системы.

Так что это правильно - убить приложение, которое не «влазит» в систему, а не невиновные.

К тому же

SIGTERM

Сначала вежливо просит. И если апа написано по канонам - она спросит у юзвере - мол меня попросили - не желаешь ли сохранить данные? :) Ну или просто сама их во временный файл сохранит - как в современных текстовых процессорах.

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

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

Вряд ли это бы помогло как-то при исчерпании памяти но всё же.

В современных дистрибутивах вроде бы у него дефолтный приоритет из коробки.

В этом плане кстати очень мешает своп. Ну т.е. он полезен когда какого-то явного перерасхода озу не будет. А вот если будет - то линукс до последнего будет пытаться справится с ситуаций используя своп. И чем меньше своп (или его вообще нет) тем быстрее система убьет разросшуюся апу.

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

OOM приходит тогда, кгда случился «оверселлинг» по памяти, который в текущих условиях не исполнить. Отключайте overcommit и добавляйте свап, и не будет к вам приходить никаких OOM.

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

Прикол в том что в Винде (как минимум начиная с 8-ки) такое есть штантно из коробки. Появляется окошечко с приблизительно такой надписью. «В системе исчерпана память, сохраните данные приложения %appName% во избежания их потери» - или что-то типа того.

С Vista

На MacOS тоже само собой давным-давнооооо есть

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

Проприертарщина она такая - все для пользователя :)

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

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

Исходники он исправить не всегда может

Если это проприетарщина, как выше писал hobbit, то ССЗБ, ничего не поделать. В противном случае обязанно пинать разработчика, а если это внутренний продукт, то и подавно.

WitcherGeralt ★★
()

earlyoom принудительно (через отправку SIGTERM или SIGKILL) завершит работу процесса, наиболее активно потребляющего память

вот я прям так и вижу картину: плачущие гентушники - какой-то earlyroom постоянно сносит их процессы, компилирующие мир.

bvn13 ★★★★★
()

А сколько памяти жрёт сам этот процесс?

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

Если тяжёлый счёт, то лучше всего использовать всю оперативу, например. Промахнулся в оценке — и перезагружайся, потому что комп встал колом.

anonymous
()

Если объём доступной памяти меньше заданного значения, то earlyoom принудительно (через отправку SIGTERM или SIGKILL) завершит работу процесса, наиболее активно потребляющего память

Эта штука будет регулярно убивать гном-шелл, файрфокс, хром, юнити? Отличное ПО!

Alve ★★★★★
()

А разве это нужно? Разве в кернеле такого нету?

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

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

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

нет чтобы питон с моно выкинуть

Пральна, зачем бороться с причиной, надо бороться с последствиями!

+1 обоим. Но на причину, увы, всем насрать, ибо капитализм и деградация worldwide.

dimgel ★★★★★
()

Для сборки нужен pandoc...

Из каментов на AUR

ehh.. It now ask for installing 100 packages. Is it possible to come up with another solution?

Это ради генерации манов?

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

а какой процесс при разработке микросхем должен пыхтеть неделю

У меня(на работе) на сервере подключен raid через cifs в условные 45тб данных.и эти 45тб документов бекапятся тулзой backup-manager. Процесс иногда висит по 5 дней. И в sar видно что под конец процесс уходит в циклический краш ... Из за нехватки оперативы.

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

ибо капитализм и деградация worldwide.

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

Где мои восьмидесятые?

mord0d ★★★★★
()
$ yaourt -S earlyoom
==> Установить или собрать отсутствующие зависимости earlyoom:

Пакеты (96) cmark-gfm-0.28.3.gfm.17-1  ghc-libs-8.6.1-1  haskell-aeson-1.4.1.0-7  haskell-aeson-pretty-0.8.7-42
            haskell-ansi-terminal-0.8.2-1  haskell-asn1-encoding-0.9.5-73  haskell-asn1-parse-0.9.4-84  haskell-asn1-types-0.3.2-80
            ...
            ...
            ...
Будет установлено:  409,78 MiB

:: Приступить к установке? [Y/n]


Круто. Но пока обойдёмся vm.overcommit + zram.

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

Нет, ванильный никогда не работал нормально.

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

Без лишних зависимостей меньше метра весит.

anonymous
()

Своп известен еще с древнейших времен. Странное поделие

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

Значит небось видеодрайвер зависает при нехватке памяти.

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

норм че, sshd он не пришиб, а bash, который sshd заспавнил, пришиб.

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

если что-то пошло не так, вызвать штатные средства очистки

Штатные средства как раз работают плохо. Поэтому из заменяем нештатными юзерспейсными демонами.

Другой вариант — если способ автора действительно даёт хороший результат, может, автор займётся патчами в ядро?

Не займется. Он ленив и даже текущие баги исправлять не хочет:

You just don't want to fix the bug.

Yes.

https://github.com/rfjakob/earlyoom/issues/97

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