LINUX.ORG.RU
ФорумTalks

Объясните для тупых дебилов: почему OOM может убить процесс, который не виновен?

 


1

2

Кажется объяснение в том, что ядро не видит глобальной картины, а видит только отдельные brk() (попытки выделения памяти), которые происходят почти всегда в любом безобидном процессе.

Допустим процесс 1 работает давно и делает brk() с частотой 1 Гц, а процесс 2 запустили только что и он делает brk() с частотой 50 Гц и отожрал почти всю свободную память. Но вызов brk(), первым столкнувшийся с концом памяти, по случайности исходил из процесса 1 и потому замочат именно его, а не 2?

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

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



Последнее исправление: hlamotron (всего исправлений: 3)

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

Deleted
()

Теоретически для каждого процесса считается /proc/<pid>/oom_score, и у самых жирных он соответствующий. По опыту на самом деле тупо вешается вся систему, убивать невиновных может только если вручную выставить /proc/sys/vm/oom_kill_allocating_task.

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

Вешается это если свап есть, и его много. Тогда OOM киллер может косу уже и взял, но идти будет ооочень долго.

ncrmnt ★★★★★
()

В ядре такой тупой алгоритм?

Ну, политика oom killer «убить минимальное количество процессов, чтобы сохранить работоспособность системы». Беда только в том, что тут победителей не бывает. Какую стратегию не выбирай - всегда будут пострадавшие, которые начнут громко плакать.

Текущий способ определения жертв основывается на /proc/<pid>/oom_score, являющимся (int)(проценты_использования_памяти * 10). Т.е. величина от 0 до 1000. Что за проценты такие? Это процент реально используемой процессом памяти. Т.е. если использует каждый выделенный байт - у него 1000 очков, не использует ничего - 0.

Что за реально используемая память такая? Ну... Тут надо вспомнить про overcommit. Память в компах страничная. Сначала процесс получает область адресного пространства, а потом прикрепляет к нему страницы памяти. Вот только процессы этим пользоваться не умеют. Нужен им большой блок памяти - они его malloc'ом выделяют. И не важно потом какую его часть использовать станут. Ядро в курсе и хитрит. Часть памяти выделяет, а часть нет. Только пометки оставляет себе - если процесс постучится в эту страницу - выделить с сделать вид, что так и было.

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

К счастью, oom killer не тупое животное. С ним по понятиям договориться можно. Пишите в /proc/<pid>/oom_score_adj -1000 и oom killer будет шарахаться от вашего процесса как от прокажённого. Пишите 1000 и считайте, что процесс уже с мешком на голове стоит перед расстрельной командой.

atrus ★★★★★
()

«Убей их всех, Бог потом отсортирует» ©

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

Х.з. наверное зависит от того, как приложение хавает память, когда оно кончается. На машинах где работаю OOM приходит очень быстро, когда память кончается. И огребают все и как попало ;)

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

Как я правильно понимаю все еще зависит от количества памяти, выделенного ядром для oom-киллера (опция в ядре). Видел, когда не срабатывал с малым параметром, и нормально срабатывал при бОльшем количестве памяти.

leg0las ★★★★★
()

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

pon4ik ★★★★★
()

ООМ приходит когда страница обещана через sbrk но не может быть предоставлена. Пока свободный свап есть оом не придёт. Не хотите видеть оом - отключайте оверкоммит. Процессы по прежнему будут валиться, но уже в юзерспейсе по allocation failef

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

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

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

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

Я лет 10 назад уже написал как OOM Killer выбирал свою жертву, сейчас все стало немного иначе, но не сильно: http://catap.ru/blog/2009/05/03/about-memory-oom-killer/

Советую в общем.

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

Не обязательно sbrk. Можно еще аллоцировать память через mmap анонимный.

Можно еще поразвлекаться с slab в linux, но это несколько странное извращение.

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

А как вы предлагаете контролировать потребление памяти?

Можно начать с простого ответа: как узнать сколько программа использует памяти?

Мне кажется что посчитать это в современном linux (со всеми его CoW) не возможно :)

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

сейчас все стало немного иначе, но не сильно

Ну, не знаю. Пишут, что довольно сильно, старую эвристику удалили в 2011 году.

Сейчас в файле даже упомянутые в вашем тексте константы и выражения не находятся.

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

И это хорошо! Старая была очень не тривиальной, давай скажем так :)

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

А как вы предлагаете контролировать потребление памяти?

настройкой серверных приложений, использованием cgroups и прочих средств администрирования, внезапно.

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

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

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

Не все приложения могут быть настроены.

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

Вы кстати так и не ответили на вопрос:

Можно начать с простого ответа: как узнать сколько программа использует памяти?

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

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

актуальность киллера возрастает на системах без свопа.

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

да что угодно. проц, память, IO.

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

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

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

Если у вас на машинах есть swap то проблемы как бы уже есть.

Далее, какую именно память ограничивает cgroups?

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

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

cvs-255 ★★★★★
()
Ответ на: комментарий от catap

ту, какая у тебя есть. если есть своп - то виртуальную. но если его отключить (что чаще всего и делают), то реальную.

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

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

Мне кажется что посчитать это в современном linux (со всеми его CoW) не возможно :)

Наверное, CoW точно учесть невозможно (не в принципе, а существующими инструментами), но это и не нужно - CoW-памяти немного.

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

ту, какая у тебя есть. если есть своп - то виртуальную. но если его отключить (что чаще всего и делают), то реальную.

Я правильно понимаю вашу мысль что если в машине нет swap то виртуальная память равна реальной (или ее нет совсем?)

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

можно рассказать как вы будете управлять потреблением памяти например в контексте ejabberd или varnish/nginx/apache?

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

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

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

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

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

к сожалению стоит начать с себя :) Если у машины нет SWAP то это никак не связано с overcommit памяти, можешь попробовать крайне простую программу на C которая выделит 100500 гигабайт памяти, и она будет запускаться не завися от наличия или отсуствия SWAP. А вот изменение overcommit может сильно изменить ее поведение.

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

Почему? Я понимаю что в тебе говорят мемы времен apache 1.3 когда все его использовали как application server с cgi/mod_php и на его фоне nginx с fastcgi и php-fmp был куда более лучший.

Сейчас же они примерно одинаковы в производительности. Там есть нюансы, но они не критичны.

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

Т.е. мы переходим не к управлению памятью, а к управлению нагрузкой, да?

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

определение маленький и легкий?

(если не написан на каком-нибудь говнопистоне, конечно). и проблем с памятью у него быть не должно вообще.

А как python связан с проблемами с памятью?

Может быть ты из тех у кого java тормозит?

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

что делать будем с slab памятью? :)

Что такое slab-память? Если имеется в виду память по служебные структуры ядра (ЕМНИП, она выделяется SLUB-аллокатором), то тоже ничего по тем же причинам, что и с CoW. Есть случаи, когда это проблема?

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

Без свопа выгрузка неанонимных страниц продолжает работать как ни в чём не бывало.

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

SLUB это аббревиатура от the unqueued slab allocator ;) так что можно использовать обе в контексте linux.

Я не знаю когда это проблема как и потребление памяти приложением — проблема.

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

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

SLUB это аббревиатура от the unqueued slab allocator ;)

Да, я знаю.

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от cvs-255

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

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

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

Т.е. мы переходим не к управлению памятью

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

определение маленький и легкий?

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

А как python связан с проблемами с памятью?

тупой и жручий до ресурсов. одним словом, типичное ненужно.

Iron_Bug ★★★★★
()
17 апреля 2020 г.
Ответ на: комментарий от Iron_Bug

так виртуальную и выжрать физически невозможно

Возможно, если специально выжирать.

пока есть своп - всё будет сыпаться туда

Вовсе не обязательно. Киллер может приходить при полупустом свопе.

размер свопа обычно во много раз превышает размер рамы

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

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

Говнокодера, который ООМ киллер реализовывал надо ногами бить, долго. Как и вообще всех, кто реализовывал распределение ресурсов машины в Linux-е, потому как те же диски побеждают годами, но оно опять возвращается.

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

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

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

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

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

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

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

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

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

Я как-то YAGF решил на тысячу сканов натравить, узнал много нового. А вообще у меня не редко памяти не хватает из-за обработки больших и не очень больших данных, да надо бы плашек доткнуть эдак до 64 гигов - но там и пекарню надо менять, а вроде если аккуратно делать и не лениться и обрабатывать данные не разом, а пачками, то и на 16 гигах жить можно.

А у тебя просто задач нет, чтобы софт использовать. Писать и вылизывать скрипты, которые 1 раз отработают по потреблению памяти, ну такое себе.

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

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

ну я и сама много чего админю. и тоже не течёт ничего нигде. наверное, руки из нужного места растут :)

если я обнаруживаю утечку памяти - я отлаживаю софт, пока её не найду и не устраню. конечно, я использую только софт на С/C++, чтобы можно было его отлаживать нормально.

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