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 ()

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

Элементарно. При разработке микросхем, например, САПРы жрут непредсказуемо много оперативы (овер 500 гигов в ряде случаев как нефиг делать). И если процесс, который пыхтел неделю прибьет OOM, то будет ооочень плохо.

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

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

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

Сколько лет ему потребуется для завершения работы, если он будет писать на диск вместо оперативы?

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

Лол, прям как я выше и написал.

Т.е. не обоснование, а просто припарка от рукожопия. Вместо решения проблемы какие-то дебильнейшие костыли.

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

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

Прежде чем придет OOM killer, твоя игра будет тормозить и свопиться, пока не сожрет весь swap, временами завешивая курсор мыши. Думаешь не заметишь и не успеешь отреагировать (хотя, если это шахматы, то такое возможно).

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

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

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

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

И ты думаешь, что если запустишь еще один процесс, который будет занимать память и периодически грузить CPU (т.е. вряд ли ядро уведомит пользовательский процесс о нехватке памяти, а, значит, нужно будет проводить регулярный опрос и при обнаружении нехватки пробегать по всем процессам), что от этого системе станет легче?

IMHO, эта программа - очередной «дефрагментатор памяти». Выглядит круто, но на практике бесполезна.

P.S. Не понимаю людей, которые покупают убогий немощный ноутбук, а потом плачутся, что у них что-то тормозит.

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

Для тех, кто не в теме: почему с подобными проблемами не справляется само ядро?

Ядро само справляется, этим занимается обработчик OOM, но он срабатывает после нескольких минут активного свопа, когда вся машина стоит колом. Хипстерам такое решение не понравилось и они сделали пользовательский процесс, который сам жрет память и CPU, но убивает процессы (и очищает память) чуть раньше.

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

Компиляция кучи вложенных шаблонных конструкций c++. Вполне себе вариант. Система иногда зависает так, что даже в другую консольную сессию не переключишься, чтобы убить процессы.

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

Но зачем, если есть Alt-SysRq-F

Предполагаю, что эта софтина для тех, кто даже с терминалом не дружит, не то что с SysRq. И при этом не хочет ждать ядерного OOM killer, потому что тот сработает сильно позднее.

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

ну некоторые CAE программы пишут данные более получаса)

и жрут при этом память больше чем при счете, хоть и не сильно больше.

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

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

Насколько я понимаю, в OOM killer чуть ли не в коде прописано, ssh и PID 1 не убивать, потому что если у тебя сервак тормозит, а ты на него по ssh зайти не можешь, то его остается только ребутнуть.

anonymous ()

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

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

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

Это когда размер жесткого диска был меньше размера оперативки в современной мобилке?

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

Нисколько, cразу станет ясно, что нужно бежать в магазин за планками озу.

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

Пусть она отправляется сразу в два варианта, и в дурочку, и в биореактор.

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

еще один процесс, который будет занимать память и периодически грузить CPU

У меня он занимает 0% ЦП и 0% памяти:

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.

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

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

Понятно, спасибо. А эти несколько минут нельзя превратить в приемлемые несколько секунд какими-нибудь опциями ООМ киллера?

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

Можно, если использовать юзерспейсный ООМК. В ядерном ООМК порог срабатывания не настраивается.

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

ну некоторые CAE программы пишут данные более получаса)

Прости, но полчаса записи? Откуда так много? 16 гигов оперативки сдампятся на SSD примерно за секунд 30-40.

А если же у них какой-нибудь изощрённый формат хранения, при сохранении в котором собственно I/O занимает 1% времени, а всё остальное — CPU-ёмкое преобразование сырых данных в этот формат, то это сложно назвать записью данных. И это точно не то, что должно происходить при аварийном завершении программы.

Crocodoom ★★★★ ()

использовать cgroups пробовали ?

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

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

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

косяки не сподвигают людей как-то их исправлять

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

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

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

Ты точно описал современный стэк разработки и внедрения.

Deleted ()

вам не кажется что логичнее было бы реализовать это в самом ядре (т.е. к примеру параметр который можно менять через /proc/ когда должен запускаться OOM-killer).

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

так и есть. одни пихают какое то говно с миллионом классов пожирающих память там где можно обойтись одним. вторые создают garbage collector'ы что бы у тупых говнокодеров не текла память. третьи убивают процессы такими утилитами. засилье идиотов и тупых заказчиков которым интересны только красивые свистоперделки в IT.

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

garbage collector

Я недавно запустил один из клонов wrk на Go, он мгновенно выжрал 16гб операвивы и весь своп. Нежданчик. GC — не спасает от рукожопия, а иногда даже ему способствует.

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

Garbage Collector это как подпись «мы не умеем работать с памятью». а всё это по моему идёт из всяческих тотально оопизированных библиотек где pointer/reference летает между миллионом ф-ций/методов туда сюда без конца. и разбирать такой код очень сложно, мне уже говорили что для этого обычного vim'а не достаточно а надо специальное IDE. да ну нахрен, зачем такое делать.

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

GitHub - wg/wrk: Modern HTTP benchmarking tool

как можно так набыдлокодить на 16 гигабайт в такой простой программе. не иначе как каждый request в объекте внутри которого каждый HTTP заголовок в другом объекте и ещё 500 объектов всем этим управляют.

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

В Go есть только структуры, которые практически бесплатные. Так как сервер отдавал довольно жирные ответы, полагаю, что они-то в памяти и остались. Я подождал пока оно сдохнет и продолжил тестировать оригинальным wrk.

Но это не проблема Go и даже не проблема GC. Не знаю как автор умудрился, в Go это очень сложно сделать не целенаправленно.

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

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

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

Garbage Collector это как подпись «мы не умеем работать с памятью

Постыдился бы невежеством сверкать. GC нужен для языков высокого уровня, где абстракции находятся как можно дальше от железа.

Представь, например, насколько неуместным было бы ручное управление памятью в каком-нибудь Матлабе или Экселе. А ведь это тоже языки, причём сверхвысокого уровня, они DSL

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

Ядро убивает с SIGKILL, а здесь есть возможность TERM.

Deleted ()

Удалена опция -k для вызова ядерного oom-killer'a

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

Хм, а почему? По идее, это как раз самый нормальный вариант — если что-то пошло не так, вызвать штатные средства очистки.

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

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

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

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

Вам смешно, а что-то подобное было в нашей практике. Когда много лет назад в проприетарной системе, купленной за сотни нефти, один из сервисов (под виндой) имел склонность к непредсказуемым падениям-зависаниям, а техподдержка слов умнее «обождите, мы вот-вот выпустим новую версию» не знает, наиболее практичным решением оказалось написать свой говносервис, который раз в полчаса проверяет состояние говносервиса из купленной системы и если что, принудительно его перезапускает. ИЧСХ, это прекрасно работало.

Да, это именно припарка от рукожопия, а деваться было некуда.

Со свободным ПО обычно полегче, в том смысле, что теоретически там всегда можно найти концы, направить багрепорт и др. Но и там есть свои проблемы.

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