linux & malloc & signal AGAIN
Vladimir Dozen
Я уже писал, но приходится возвращаться: процесс ведет
себя не так, как положено при исчерпании памяти, а именно
тихо умирает, не поймав ни сигнала, ни null-pointer'а.
Не помню, кто уж тут мне посоветовал записать 1 в
/proc/sys/vm/overcommit_memory, но это не работает.
malloc (или operator new, это не суть) отдает валидный адрес
блока, но при попытке его заполнить (а память кончилась)
процесс убивают. Ни тебе сигнала, ни NULL-pointer'а.
Ну и как под такой системой жить? :(((
--
dozen @ home
Valentin Nechayev
VD> Я уже писал, но приходится возвращаться: процесс ведет
VD> себя не так, как положено при исчерпании памяти, а именно
VD> тихо умирает, не поймав ни сигнала, ни null-pointer'а.
VD> Не помню, кто уж тут мне посоветовал записать 1 в
VD> /proc/sys/vm/overcommit_memory, но это не работает.
VD> malloc (или operator new, это не суть) отдает валидный адрес
VD> блока, но при попытке его заполнить (а память кончилась)
VD> процесс убивают. Ни тебе сигнала, ни NULL-pointer'а.
VD> Ну и как под такой системой жить? :(((
1. Посмотреть, что такое OOM killer. Отключить, если хочется ездить
без тормозов.
2. Расставить правильно limit'ы, чтобы процесс не попадал в эту позу.
/netch
Vladimir Dozen
> без тормозов.
> 2. Расставить правильно limit'ы, чтобы процесс не попадал в эту позу.
Посмотрел, расставил. Как обычно, гнушники все сделали
не так (как я хочу ;).
1. OOM killer, конечно, бальзам на сердце админам, потому что
им дают еще одну ручечку, которую они могут покрутить, но
для программера этот OOM -- как козе баян; самая простая
ситуация -- числомолотилка. На всю систему два ;) процесса
-- sshd и p.model.server (data mining, однако). Задача
программера -- обеспечить некую стабильность при граничных
условиях, в частности, при нехватке памяти.
Числожорка выедает всю память, OOM killer в раздумьях --
кого убить? Если решает убить sshd, то числожорка тут же
просит еще двадцать мегабайт, и ее таки приходится прибить;
имеем эффективный DOS. Если сразу убивает числожорку, то одна
радость -- можно зайти по ssh и запустить ее снова. И так раз
в пятнадцать минут.
В общем, не работает тут OOM killer.
2. ulimit AKA setrlimit. О, тут я был в восторге! Если я выделяю
память в data segment (malloc/operator new) -- какой по-вашему
лимит я должен выставить? RLIMIT_DATA? Под нормальными системами --
да, его. Под линуксом -- RLIMIT_AS (address space). RLIMIT_DATA
нисколько не препятствует произвольному росту хипа. Ж:()
Кроме того, как нетрудно догадаться, лимиты действуют на один
процесс; при форканье мы шустро движемся в пункт 1 со всеми
вытекающими.
Я вот чего не пойму -- почему мне не прислать SIGBUS, если я обращаюсь
к странице, которая не может быть отмаплена по причине недостатка
памяти? Ведь я ловлю этот сигнал, делаю throw bad_alloc(), раскручиваю
стек и освобождаю кучу памяти -- сам, без помощи какого-то OOM killer!
Парни, может кто сделает патч для linux?
--
dozen @ home
Alexander Gordeyev
> Я вот чего не пойму -- почему мне не прислать SIGBUS, если я обращаюсь
> к странице, которая не может быть отмаплена по причине недостатка
> памяти?
почему?
вот не знаю, можно ли в оригинале поймать SIGBUS при проблемах с железом, но
в Linux у него другая семанитка. и получить его можно только в криво написанном
юзерском процессе. а менять семантику - зло!
то, чего тебе хочется более подходит механизму kevent'ов, увы.
> Ведь я ловлю этот сигнал, делаю throw bad_alloc(), раскручиваю
> стек и освобождаю кучу памяти -- сам, без помощи какого-то OOM killer!
ээээ.. ммм. а что делать ядру, если какой-нибудь умелец ловит сигнал, но стек
не раскручивает? user-level callback'и вводить? или OOM killer писать? :-)))
баловство это.
> Парни, может кто сделает патч для linux?
ииэх!
--
With best regards, Alexander Gordeyev
AGAVA Software Company, http://www.agava.com
yx
> Я уже писал, но приходится возвращаться: процесс ведет
> себя не так, как положено при исчерпании памяти, а именно
> тихо умирает, не поймав ни сигнала, ни null-pointer'а.
>
> Не помню, кто уж тут мне посоветовал записать 1 в
> /proc/sys/vm/overcommit_memory, но это не работает.
> malloc (или operator new, это не суть) отдает валидный адрес
> блока, но при попытке его заполнить (а память кончилась)
> процесс убивают. Ни тебе сигнала, ни NULL-pointer'а.
>
(сразу инициализируя) в беск.цикле(до получения null от malloc) всю память.
Попробовал linux2.4, freebsd4.2rc1, netbsd1.5,
ни в одной из них от malloc() null не получил,
при этом поведение они демонстрируют абсолютно разное:
в nbsd получает сильное торможение - но все хоть и медленно но живет;
в linux - отрабатывал oom killer, четко пристрелив именно этот процесс;
в fbsd - получил killed, затем заметил странные вещи - сдохли X
и отвалился pppd, named, и бог знает что еще (maybe rc? don't know)
или я о чем-то не о том? тогда код покажи.
> Ну и как под такой системой жить? :(((
>
процесс тихо умер, пристрелив сессию root'а в соседней консоли. :)))
bye.
--
Vladimir Yakovetsky
Valentin Nechayev
>> Я вот чего не пойму -- почему мне не прислать SIGBUS, если я обращаюсь
>> к странице, которая не может быть отмаплена по причине недостатка
>> памяти?
AG> почему?
AG> вот не знаю, можно ли в оригинале поймать SIGBUS при проблемах с железом, но
AG> в Linux у него другая семанитка. и получить его можно только
AG> в криво написанном
AG> юзерском процессе. а менять семантику - зло!
AG> то, чего тебе хочется более подходит механизму kevent'ов, увы.
kevent - для асинхронных событий.
Отсутствие места под страницу - никак не асинхронное.
>> Ведь я ловлю этот сигнал, делаю throw bad_alloc(), раскручиваю
>> стек и освобождаю кучу памяти -- сам, без помощи какого-то OOM killer!
AG> ээээ.. ммм. а что делать ядру, если какой-нибудь умелец ловит сигнал,
AG> но стек не раскручивает? user-level callback'и вводить? или
AG> OOM killer писать? :-)))
Хотя бы. Хотя мне больше нравится идея нормально работающих (а не через
анус) лимитов и демпфирование исчерпания критических ресурсов.
AG> баловство это.
С каких пор обеспечение нормального качества работы стало баловством?
Кстати, на вопрос, где берутся компьютеры с неограниченными ресурсами,
Вы не ответили.;))
/netch
Valentin Nechayev
y> попробовал, только что, без лимитов от юзера выжирать страницами
y> (сразу инициализируя) в беск.цикле(до получения null от malloc) всю память.
y> Попробовал linux2.4, freebsd4.2rc1, netbsd1.5,
y> ни в одной из них от malloc() null не получил,
y> при этом поведение они демонстрируют абсолютно разное:
y> в nbsd получает сильное торможение - но все хоть и медленно но живет;
y> в linux - отрабатывал oom killer, четко пристрелив именно этот процесс;
y> в fbsd - получил killed, затем заметил странные вещи - сдохли X
y> и отвалился pppd, named, и бог знает что еще (maybe rc? don't know)
Старая фря у тебя. Новая пристрелит именно этот процесс.
/netch
Valentin Nechayev
>> 1. Посмотреть, что такое OOM killer. Отключить, если хочется ездить
>> без тормозов.
>> 2. Расставить правильно limit'ы, чтобы процесс не попадал в эту позу.
VD> Посмотрел, расставил. Как обычно, гнушники все сделали
VD> не так (как я хочу ;).
VD> 1. OOM killer, конечно, бальзам на сердце админам, потому что
VD> им дают еще одну ручечку, которую они могут покрутить, но
VD> для программера этот OOM -- как козе баян; самая простая
VD> ситуация -- числомолотилка. На всю систему два ;) процесса
VD> -- sshd и p.model.server (data mining, однако). Задача
VD> программера -- обеспечить некую стабильность при граничных
VD> условиях, в частности, при нехватке памяти.
VD>
VD> Числожорка выедает всю память, OOM killer в раздумьях --
VD> кого убить? Если решает убить sshd, то числожорка тут же
VD> просит еще двадцать мегабайт, и ее таки приходится прибить;
VD> имеем эффективный DOS. Если сразу убивает числожорку, то одна
VD> радость -- можно зайти по ssh и запустить ее снова. И так раз
VD> в пятнадцать минут.
VD>
VD> В общем, не работает тут OOM killer.
Весьма аналогичное OOM killer'у средство есть во FreeBSD.
Оно отстреливает самый толстый процесс из тех, что работают или хотят память.
Точнее, самый толстый - это где-то с месяц, до того была ошибка
и стреляло "самый резидентный". ;))
Вообще, эта проблема _нормально_ не решается IMO нигде, можно получить
только некоторое приближение к тому, как было бы нормально.
Где-то числожорка важнее даже init'а ;)), где-то - ее можно рубить каждую
минуту, а вот sshd надо обеспечить. Если бы было сделано:
1) по исчерпанию >90% VM, память нерутовым процессам не дается,
2) по приближению к критическим границам, процессам дается извещение
о том, что неплохо бы умерить аппетиты (например, сборку мусора провести),
3) lazy commit исполняется только для тех областей памяти для которых
он явно заказан,
4) нет глупых аппликух которые рассчитаны на тотальный lazy commit,
- было бы получше. Но это уже, увы, целая программа действий, делать
которые неинтересно. Видели же как пишутся, например, куски GNOME?
Никакое выделение памяти не проверяется на успешность, потому что по
неуспешном выделении g_new() немедленно хлопает программу.
Даже если это большое толстое приложение с расчетом на долгую работу.
И даже при precommit'е есть проблемы.
Замапили so'шку в память. Поставили в PIC области правильные ссылки.
Кто должен был сказать что памяти нет? mprotect?
VD> 2. ulimit AKA setrlimit. О, тут я был в восторге! Если я выделяю
VD> память в data segment (malloc/operator new) -- какой по-вашему
VD> лимит я должен выставить? RLIMIT_DATA? Под нормальными системами --
VD> да, его. Под линуксом -- RLIMIT_AS (address space). RLIMIT_DATA
VD> нисколько не препятствует произвольному росту хипа. Ж:()
Вообще-то, RLIMIT_DATA - это размер именно области данных.
А область данных - это то, граница чего сдвигается по sbrk().
А malloc в glibc работает не по sbrk, а по mmap. mmap'ленные области - это
не совсем область данных.
Так что здесь, мне кажется, логика именно в RLIMIT_AS есть.
Или есть правило что mmap'ленные области должны включаться в размер,
ограничиваемый по RLIMIT_DATA? Где такое?
VD> Кроме того, как нетрудно догадаться, лимиты действуют на один
VD> процесс; при форканье мы шустро движемся в пункт 1 со всеми
VD> вытекающими.
VD>
VD> Я вот чего не пойму -- почему мне не прислать SIGBUS, если я обращаюсь
VD> к странице, которая не может быть отмаплена по причине недостатка
VD> памяти? Ведь я ловлю этот сигнал, делаю throw bad_alloc(), раскручиваю
VD> стек и освобождаю кучу памяти -- сам, без помощи какого-то OOM killer!
VD> Парни, может кто сделает патч для linux?
И ты его будешь расставлять на своих машинах?
/netch
yx
>> ни в одной из них от malloc() null не получил,
>> при этом поведение они демонстрируют абсолютно разное:
>> в nbsd получает сильное торможение - но все хоть и медленно но живет;
>> в linux - отрабатывал oom killer, четко пристрелив именно этот процесс;
>> в fbsd - получил killed, затем заметил странные вещи - сдохли X
>> и отвалился pppd, named, и бог знает что еще (maybe rc? don't know)
>
> Старая фря у тебя. Новая пристрелит именно этот процесс.
>
"very glad" был мой знакомый с фрей к которому я приконнектился для пробы.
А то что кого-то все равно пристреливают - то что здесь хорошего?
с моей колокольни "very пофигу" выглядел бы так:
появился ресурс - получи, нет - лежи в свопе / отдыхай / жди, или получай 0,
в зависимости от типа своего запроса,
при этом kernel все свои базовые функции должен гарантировать.
bye.
--
Vladimir Yakovetsky
Valentin Nechayev
>> Старая фря у тебя. Новая пристрелит именно этот процесс.
y> "very glad" был мой знакомый с фрей к которому я приконнектился для пробы.
y> А то что кого-то все равно пристреливают - то что здесь хорошего?
OK. Предложите другое поведение в том случае, когда память исчерпалась
вся. Включая своп. А какое-то приложение хочет еще.
А удовлетворить возможности нет. А ведь еще где-то должны сетевые
пакетики складываться.
Я такие позы специально наблюдал и вызывал.
Намертво зависший linux (без OOM killer'а), который ничего не делает,
просто висит в позе зю. Разве что на консоль пишутся "do_try_free_pages
failed for process XXX". И мертвые с косами стоят;))
Единственное, чем лечилось - magic SysRq. Нажмешь Alt-SysRq-e - и становится
спокойно и просторно, как на кладбище. Только вот процессы куда-то все
подевались, интересно, куда?;))))
Аналогичная фряха. Только эта через пару минут все же прочухалась и постреляла
top, systat и еще кого-то, а потом и пожирателя памяти.
Правда, и пара минут была один раз - в остальные спасалось за несколько
секунд активного мЫшления.
y> с моей колокольни "very пофигу" выглядел бы так:
y> появился ресурс - получи, нет - лежи в свопе / отдыхай / жди, или получай 0,
y> в зависимости от типа своего запроса,
y> при этом kernel все свои базовые функции должен гарантировать.
Не будет такое работать.
/netch
Vladimir Dozen
У меня новая -- 5.0-CURRENT. Убивают "этот" процесс, но и
httpd по ходу сдох ;(
--
dozen @ home
Vladimir Dozen
> (сразу инициализируя) в беск.цикле(до получения null от malloc) всю память.
Да, именно так я тестировал, плюс регистрировал все сигналы от 1 до 64.
> в linux - отрабатывал oom killer, четко пристрелив именно этот процесс;
> или я о чем-то не о том? тогда код покажи.
Именно. А следовало бы предварительно сообщить процессу о грядущем
прибитии, потому что он, с определенной вероятностью, способен сам
освободить память, то есть "договориться с системой по-хорошему".
Зачем сразу убивать-то?
--
dozen @ home
Vladimir Dozen
> вот не знаю, можно ли в оригинале поймать SIGBUS при проблемах с железом, но
> в Linux у него другая семанитка. и получить его можно только в криво
> написанном юзерском процессе. а менять семантику - зло!
Если я лезу в неотмапленную страницу -- неважно, у меня junk pointer
или кончилась физическая память -- я всегда должен получать SIGBUS.
Где ты видишь "изменение семантики"?
> то, чего тебе хочется более подходит механизму kevent'ов, увы.
Я таковых не знаю. Я пишу не под linux, а под SUS или около того.
> > Ведь я ловлю этот сигнал, делаю throw bad_alloc(), раскручиваю
> > стек и освобождаю кучу памяти -- сам, без помощи какого-то OOM killer!
>
> ээээ.. ммм. а что делать ядру, если какой-нибудь умелец ловит сигнал, но стек
> не раскручивает? user-level callback'и вводить? или OOM killer писать? :-)))
То же самое, что делается при shutdown -- вначале посылается SIGTERM,
затем, после какой-то паузы, SIGKILL. Здесь будет SIGBUS, пауза,
повторная попытка отмапить страницу, SIGKILL.
> баловство это.
Баловство -- в штанах. А за это деньги платят.
--
dozen @ home
Vladimir Dozen
> 2) по приближению к критическим границам, процессам дается извещение
> о том, что неплохо бы умерить аппетиты (например, сборку мусора провести),
> 3) lazy commit исполняется только для тех областей памяти для которых
> он явно заказан,
> 4) нет глупых аппликух которые рассчитаны на тотальный lazy commit,
Это все равно вариации на тему OOM killer, то есть "умный системный
программист, тупой прикладной". Я хочу строго обратного -- чтобы сначала
у приложения поинтересовались, а не ослабит ли оно свои требования к
памяти? а уж потом, если оно тупое, то и убить можно.
Сейчас же мне просто НИКАК не обеспечить живучесть в условиях нехватки
памяти, при том, что эта нехватка для меня -- норма.
> - было бы получше. Но это уже, увы, целая программа действий, делать
> которые неинтересно. Видели же как пишутся, например, куски GNOME?
> Никакое выделение памяти не проверяется на успешность, потому что по
> неуспешном выделении g_new() немедленно хлопает программу.
> Даже если это большое толстое приложение с расчетом на долгую работу.
Это потому, что throw нет. В аналогичных условиях у меня bad_alloc()
раскручивает стек до того места, где я поставил catch, то есть до
начала большой обработки, попутно уничтожая все "объемистые" объекты.
Клиент получает CORBA::SystemException, и все имеют возможность
трудиться дальше.
> Вообще-то, RLIMIT_DATA - это размер именно области данных.
> А область данных - это то, граница чего сдвигается по sbrk().
> А malloc в glibc работает не по sbrk, а по mmap. mmap'ленные области - это
> не совсем область данных.
> Так что здесь, мне кажется, логика именно в RLIMIT_AS есть.
Я могу понять причину, но я выделяю память именно в сегменте данных,
и хочу, чтобы RLIMIT_DATA этот сегмент ограничивал. _AS включает
в себя и стек, и код. Если уж так получилось, то надо было сделать
_DATA == _AS.
> Или есть правило что mmap'ленные области должны включаться в размер,
> ограничиваемый по RLIMIT_DATA? Где такое?
Нет такого. Даже наоборот, про mmap явно сказано, что оно will fail,
только если _AS будет превышен. Но мне, как разработчику, почему
должно быть важно, с помощью какого механизма выделяется для меня
память? Это все интимные подробности жизни системы.
> И ты его будешь расставлять на своих машинах?
Нет, во-первых, если он войдет в какое-то ядро, то я в
requirements буду писать "ядро такое-то или новее", а
во-вторых буду явно следить, чтобы именно это ядро стояло
у тестеров и клиентов.
--
dozen @ home
Valentin Nechayev
>> Старая фря у тебя. Новая пристрелит именно этот процесс.
VD> У меня новая -- 5.0-CURRENT. Убивают "этот" процесс, но и
VD> httpd по ходу сдох ;(
=== cut ===
dillon 2001/06/09 11:06:58 PDT
Modified files:
sys/vm vm_map.c vm_map.h vm_pageout.c
Log:
Two fixes to the out-of-swap process termination code. First, start killing
processes a little earlier to avoid a deadlock. Second, when calculating
the 'largest process' do not just count RSS. Instead count the RSS + SWAP
used by the process. Without this the code tended to kill small
inconsequential processes like, oh, sshd, rather then one of the many
'eatmem 200MB' I run on a whim :-). This fix has been extensively tested on
-stable and somewhat tested on -current and will be MFCd in a few days.
Shamed into fixing this by: ps
Revision Changes Path
1.202 +36 -1 src/sys/vm/vm_map.c
1.64 +2 -1 src/sys/vm/vm_map.h
1.177 +9 -4 src/sys/vm/vm_pageout.c
=== end cut ===
=== cut ===
dillon 2001/06/13 00:26:59 PDT
Modified files: (Branch: RELENG_4)
sys/vm vm_map.c vm_map.h vm_pageout.c
Log:
MFC the two out-of-swap fixes (kill the correct process and start blasting
away at processes a little earlier, before the machine begins to lockup)
Revision Changes Path
1.187.2.9 +36 -1 src/sys/vm/vm_map.c
1.54.2.2 +2 -1 src/sys/vm/vm_map.h
1.151.2.8 +9 -4 src/sys/vm/vm_pageout.c
=== end cut ===
/netch
Valentin Nechayev
>> 1) по исчерпанию >90% VM, память нерутовым процессам не дается,
>> 2) по приближению к критическим границам, процессам дается извещение
~~~~~~~~~~~~~~~~~~~~~~~~~~
>> о том, что неплохо бы умерить аппетиты (например, сборку мусора провести),
>> 3) lazy commit исполняется только для тех областей памяти для которых
>> он явно заказан,
>> 4) нет глупых аппликух которые рассчитаны на тотальный lazy commit,
VD> Это все равно вариации на тему OOM killer, то есть "умный системный
VD> программист, тупой прикладной". Я хочу строго обратного -- чтобы сначала
VD> у приложения поинтересовались, а не ослабит ли оно свои требования к
VD> памяти? а уж потом, если оно тупое, то и убить можно.
См. подчеркнутое.
Я говорил же о том, что такое извещение можно дать не всегда и обработать
его - тоже не всегда. А заодно не написал о том, что иногда хрен посчитаешь,
сколько же памяти из shared области на кого писать.;|
Извещение прислать - можно. Кажется, на IRIX шлется SIGDANGER.
А вот "сначала парочку добрых SIGBUS'ов а потом нафиг с пляжа" - это вам
не код куячить, это уже думать надо.
/netch
yx
>>> Старая фря у тебя. Новая пристрелит именно этот процесс.
>
> Log:
> Two fixes to the out-of-swap process termination code. First, start killing
> processes a little earlier to avoid a deadlock. Second, when calculating
> the 'largest process' do not just count RSS. Instead count the RSS + SWAP
> used by the process. Without this the code tended to kill small
> inconsequential processes like, oh, sshd, rather then one of the many
> 'eatmem 200MB' I run on a whim :-). This fix has been extensively tested on
> -stable and somewhat tested on -current and will be MFCd in a few days.
>
> Log:
> MFC the two out-of-swap fixes (kill the correct process and start blasting
> away at processes a little earlier, before the machine begins to lockup)
>
в oom killer анализ побогаче просто largest rss+swap :
The goals of the OOM killer are diverse:
* don't kill important system services, otherwise the system would
still be as good as dead
* minimise the amount of work lost
* free up as much memory as possible
* be predictable, don't cause nasty surprises
* be simple and small
The OOM killer uses the following factors to chose which process to
kill in an out of memory situation:
* memory use, the more memory a process is using, the more memory we
will free up and the higher the likelyhood that this program is
too big for the system and couldn't have run to completion anyway
+ more memory use increases the likelyhood of being killed
* CPU use, the more processor time a process has used, the more work
will be lost if we kill this process
+ more cpu time decreases the chance of being killed
* time since start time, the longer a process has been running, the
more likely it is that the process is stable and not "guilty" of
exhausting system resources
+ a longer run time decreases the chance of being killed
* system administrator rights, usually only trusted programs and
important system programs run as root or with capabilities enabled
+ running as root decreases the chance of being killed
* direct hardware access, killing a process which has direct
hardware access may lead to hardware getting confused and the
machine hanging; also, programs with direct hardware access are
usually important for whatever task the system is doing
+ direct hardware access decreases the chance of being killed
p.s. правда все равно просто тактические действия в критический момент
(хоть и поразумней), и также полное отсутствие упреждающих действий.((
bye.
--
Vladimir Yakovetsky
yx
>>> Старая фря у тебя. Новая пристрелит именно этот процесс.
>> "very glad" был мой знакомый с фрей к которому я приконнектился для пробы.
>> А то что кого-то все равно пристреливают - то что здесь хорошего?
>
> OK. Предложите другое поведение в том случае, когда память исчерпалась
> вся. Включая своп. А какое-то приложение хочет еще.
> А удовлетворить возможности нет. А ведь еще где-то должны сетевые
> пакетики складываться.
>
во многих случаях неоднократно предлагалось, вовсе не мной - упреждать
о чем-то подобном и Вы здесь писали.
Плохо не наличие средств подобных oom killer - так называемых emergency
recovery code, а то что и как они делают в этот emergency момент, и чем
занимаются(в смысле ничем) до. Здесь только анализ "кого наказать отстрелив",
даже не попытавшись "поставить в угол".
"Закон справедлив, но это закон" в данной ситуации слабый аргумент.
Варианты могут быть разл-е, начиная от "последнего китайского предупреждения"
до возможного бортирования "в угол" в кору на диск (файл/доб.своп/etc.),
при этом наличие некоторой emergency recovery memory даст нек-ю гарантию
удолетворения минимальных потребностей на нек-е время, нп тех кто не попал
в роль жертвы тому же аналитику из killer'а.
впрочем это все теория (блин чуть не написал метафизика,))
реально есть только примитивные киллеры, как далеко не самое оригинальное
решение.
> Я такие позы специально наблюдал и вызывал.
> Намертво зависший linux (без OOM killer'а), который ничего не делает,
> просто висит в позе зю. Разве что на консоль пишутся "do_try_free_pages
> failed for process XXX". И мертвые с косами стоят;))
> Единственное, чем лечилось - magic SysRq. Нажмешь Alt-SysRq-e - и становится
> спокойно и просторно, как на кладбище. Только вот процессы куда-то все
> подевались, интересно, куда?;))))
>
а его также можно назвать emergency recovery code, только интерактивный
и довольно слабофункциональный. Впрочем чтобы нормально потушить тазик,
находящийся в ступоре или для нек-й отладки вполне годится, а на "более того"
его не планировали.
> Аналогичная фряха. Только эта через пару минут все же прочухалась и постреляла
> top, systat и еще кого-то, а потом и пожирателя памяти.
> Правда, и пара минут была один раз - в остальные спасалось за несколько
> секунд активного мЫшления.
>
запишем для себя "значит мне не везло с фри".
>> с моей колокольни "very пофигу" выглядел бы так:
>> появился ресурс - получи, нет - лежи в свопе / отдыхай / жди, или получай 0,
>> в зависимости от типа своего запроса,
>> при этом kernel все свои базовые функции должен гарантировать.
>
> Не будет такое работать.
>
можно было спросить "why", но предвижу ответ "that is why" ,))
посему пойду я лучше пить "гарячий кофе в жаркий день".
bye.
--
Vladimir Yakovetsky
Valentin Nechayev
>> OK. Предложите другое поведение в том случае, когда память исчерпалась
>> вся. Включая своп. А какое-то приложение хочет еще.
>> А удовлетворить возможности нет. А ведь еще где-то должны сетевые
>> пакетики складываться.
y> во многих случаях неоднократно предлагалось, вовсе не мной - упреждать
y> о чем-то подобном и Вы здесь писали.
Да. Упреждать. Потому что когда ресурс исчерпался - поздно пить боржоми.
>>> с моей колокольни "very пофигу" выглядел бы так:
>>> появился ресурс - получи, нет - лежи в свопе / отдыхай / жди, или получай 0,
>>> в зависимости от типа своего запроса,
>>> при этом kernel все свои базовые функции должен гарантировать.
>> Не будет такое работать.
y> можно было спросить "why", но предвижу ответ "that is why" ,))
y> посему пойду я лучше пить "гарячий кофе в жаркий день".
Ответ обширнее;)): потому что практика показывает, что если уж
ресурс действительно исчерпался - то все, что остается делать,
это стрелять кого попало.
Поэтому для любого из критических ресурсов надо делать демпфер.
/netch
Alexander Gordeyev
> AG> в Linux у него другая семанитка. и получить его можно только
> AG> в криво написанном
> AG> юзерском процессе. а менять семантику - зло!
> AG> то, чего тебе хочется более подходит механизму kevent'ов, увы.
> kevent - для асинхронных событий.
> Отсутствие места под страницу - никак не асинхронное.
да, вы правы. kevent отдыхают еще и по другим причинам.
> AG> ээээ.. ммм. а что делать ядру, если какой-нибудь умелец ловит сигнал,
> AG> но стек не раскручивает? user-level callback'и вводить? или
> AG> OOM killer писать? :-)))
> Хотя бы. Хотя мне больше нравится идея нормально работающих (а не через
> анус) лимитов и демпфирование исчерпания критических ресурсов.
ну, пожалуй, из существующих механизмов это наиболее подходящий.
впрочем, это не снимает желательности иметь прямой OOM Killer.
> AG> баловство это.
> С каких пор обеспечение нормального качества работы стало баловством?
обеспечение нормального качества работы - это достойное занятие, которое
никак нельзя назвать баловством.
> Кстати, на вопрос, где берутся компьютеры с неограниченными ресурсами,
> Вы не ответили.;))
машина Тьюринга пойдет? :)))
я не знаю, как ответить на такой вопрос. попробуйте задать его по-другому.
Valentin Nechayev
>> 2) по приближению к критическим границам, процессам дается извещение
>> о том, что неплохо бы умерить аппетиты (например, сборку мусора провести),
AG> угу, именно это я и имел в виду. только не сработает :(
AG> со стороны ядра после раздачи извещений, процессы могут не только не вернуть
AG> память, но и попросить новую (в процессе той же сборки мусора). тогда ядру
AG> придется пристреливать кого-то принудительно, что суть тот же OOM Killer.
Нет. Никого не надо подстреливать принудительно, если ресурсы для
собственно системы есть. Надо ему просто не дать еще памяти.
Вот тут уже можно SIGBUS'ами стреляться, если происходит автокоммит
изменяемой страницы, или послать нафиг sbrk() или mmap() если они делают
явное выделение памяти.
Убивать процесс совсем - это аварийный метод, когда уже системе
для ее текущей возни не хватит памяти и надо что-то делать срочно.
А если процесс хочет еще памяти в процессе сборки мусора - это
уже проблемы его конструкции. Я бы не давал.
AG> можно после отправки извещения переводить процессы в предсмертное состояние,
AG> в котором они не могут попросить больше X страниц памяти, и по окончании
AG> сборки, получив уведомление от процесса, переводить их в обычное состояние.
Можно и так.
AG> ну или чего-нибудь в таком духе, только не по юниховски это.
Ну это проблема только для тех у кого в голове идеологические тараканы.
AG> короче, опять встает вопрос доставки извещения.
Сигнал послать.
AG> со стороны юзерского процесса написание программы (если только в качестве
AG> механизма доставки извещения не выбран непонятно какой сигнал) становится
AG> весьма изощренным упражнением.
Да не очень. Всего лишь научиться писать качественно.
А если программа написана криво - ну хлопнется, ну так на то она
и рассчитана;(
/netch
Alexander Gordeyev
> 2) по приближению к критическим границам, процессам дается извещение
> о том, что неплохо бы умерить аппетиты (например, сборку мусора провести),
угу, именно это я и имел в виду. только не сработает :(
со стороны ядра после раздачи извещений, процессы могут не только не вернуть
память, но и попросить новую (в процессе той же сборки мусора). тогда ядру
придется пристреливать кого-то принудительно, что суть тот же OOM Killer.
можно после отправки извещения переводить процессы в предсмертное состояние,
в котором они не могут попросить больше X страниц памяти, и по окончании
сборки, получив уведомление от процесса, переводить их в обычное состояние.
ну или чего-нибудь в таком духе, только не по юниховски это.
короче, опять встает вопрос доставки извещения.
со стороны юзерского процесса написание программы (если только в качестве
механизма доставки извещения не выбран непонятно какой сигнал) становится
весьма изощренным упражнением.
yx
А я наличие подобных киллеров понимаю только как альтернативу кнопке
(можешь считать что твоя софтина вводит такие os в ступор и вместе
с ней погибает), что немного изящней чем кнопка питания.
Но это проблема существующая не только в одном линухе
(не говоря даже о разл. версиях) посему "птачь" на os-version-N
в качестве решения вообще не должен рассматриваться.
Может в самой софтине попробовать не добиваться "дня X"? - ведь
все os не поправишь.
во! вспомнил:
из каждого безвыходного положения есть, по крайней мере, два выхода -
надо их только найти. :)))
bye.
--
Vladimir Yakovetsky
Alexander Gordeyev
> > в Linux у него другая семанитка. и получить его можно только в криво
> > написанном юзерском процессе. а менять семантику - зло!
>
> Если я лезу в неотмапленную страницу -- неважно, у меня junk pointer
> или кончилась физическая память -- я всегда должен получать SIGBUS.
> Где ты видишь "изменение семантики"?
начну с того, что я совершенно честно не знаю точно, в каких случаях должен
приходить SIGBUS. возможно скажут здесь. в моих изысканиях конкретно в Linux я
не нашел способа получить SIGBUS как нотификацию проблем _ядра_.
кстати, если junk pointer - это то, что я думаю, то не SIGSEGV ли должен
приходить?
> > то, чего тебе хочется более подходит механизму kevent'ов, увы.
> Я таковых не знаю. Я пишу не под linux, а под SUS или около того.
а в linux их тоже нету пока :))
> > ээээ.. ммм. а что делать ядру, если какой-нибудь умелец ловит сигнал, но
> > стек
> > не раскручивает? user-level callback'и вводить? или OOM killer писать?
> > :-)))
> То же самое, что делается при shutdown -- вначале посылается SIGTERM,
> затем, после какой-то паузы, SIGKILL. Здесь будет SIGBUS, пауза,
> повторная попытка отмапить страницу, SIGKILL.
ну это звучит разумно. только какая должна быть пауза? а если за этот таймаут
процесс еще памяти попросит? а если у него код, который должен отдать память
еще не замаплен?
Alexander Gordeyev
> А я наличие подобных киллеров понимаю только как альтернативу кнопке
> (можешь считать что твоя софтина вводит такие os в ступор и вместе
> с ней погибает), что немного изящней чем кнопка питания.
это гораздо изящней, чем кнопка питания, потому что гарантируется как минимум
целостность файловых систем. наверняка что-то еще (админы могут подсказать).
> Hо это проблема существующая не только в одном линухе
> (не говоря даже о разл. версиях) посему "птачь" на os-version-N
> в качестве решения вообще не должен рассматриваться.
да.
> Может в самой софтине попробовать не добиваться "дня X"? - ведь
> все os не поправишь.
проблема может быть в другой софтине, скушавшей много ресурсов.
кроме того данная рекомендация звучит подобно "пишите программы правильно" :)
> во! вспомнил:
> из каждого безвыходного положения есть, по крайней мере, два выхода -
> надо их только найти. :)))
даже если тебя съели у тебя остается еще два выхода (C)
Alexander Gordeyev
> Hет. Hикого не надо подстреливать принудительно, если ресурсы для
> собственно системы есть. Hадо ему просто не дать еще памяти.
> Вот тут уже можно SIGBUS'ами стреляться, если происходит автокоммит
> изменяемой страницы, или послать нафиг sbrk() или mmap() если они делают
> явное выделение памяти.
ну ладно, я понял, что про SIGBUS мне не расскажут. если доны говорят, что
можно, значит можно.
ну а такой расклад считается нормальным в UNIX-way? процесс обращается к
_валидному_ виртуальному адресу, ядро пытается подмапить страничку,
обламывается и посылает в процесс _SIGBUS_?
> Убивать процесс совсем - это аварийный метод, когда уже системе
> для ее текущей возни не хватит памяти и надо что-то делать срочно.
ну да, да. при наличии лимитов это канает.
> А если процесс хочет еще памяти в процессе сборки мусора - это
> уже проблемы его конструкции. Я бы не давал.
код сборщика мусора всегда должен быть mlock'ed в таком случае?
> Можно и так.
> AG> ну или чего-нибудь в таком духе, только не по юниховски это.
> Hу это проблема только для тех у кого в голове идеологические тараканы.
да мне ваще по фигу, я - виндузятник :)))))
Vladimir Dozen
Как? Я над этим уже месяц бьюсь. Предусмотреть размер того,
что получится при построении юзером модели, я не могу. Ulimit'ы
ненадежны и требуют ручного вмешательства. NULL мне не дают.
Signal'ы мне не шлют. Как неродной прям, блин...
--
dozen @ home
Vladimir Dozen
> > или кончилась физическая память -- я всегда должен получать SIGBUS.
> > Где ты видишь "изменение семантики"?
>
> начну с того, что я совершенно честно не знаю точно, в каких случаях должен
> приходить SIGBUS. возможно скажут здесь. в моих изысканиях конкретно в Linux я
> не нашел способа получить SIGBUS как нотификацию проблем _ядра_.
Это в linux; под hpux я их по собственной глупости ловлю постоянно --
доступ к невыровненным данным, например.
> кстати, если junk pointer - это то, что я думаю, то не SIGSEGV ли должен
> приходить?
Ну, я SIGSEGV только от *((void*)0) получал, afair.
> > То же самое, что делается при shutdown -- вначале посылается SIGTERM,
> > затем, после какой-то паузы, SIGKILL. Здесь будет SIGBUS, пауза,
> > повторная попытка отмапить страницу, SIGKILL.
>
> ну это звучит разумно. только какая должна быть пауза? а если за этот таймаут
> процесс еще памяти попросит? а если у него код, который должен отдать память
> еще не замаплен?
Пауза -- несколько time-slices. Реально этого хватает для вызова
деструкторов. Ну, скажем, секунда, чтобы с большим запасом. Не успел --
все, каюк.
Еще памяти не попросит, иначе это дурная программа. (Хотя, строго говоря,
даже throw Oops(); делает копию объекта, то есть хочет немного памяти,
так что нужен небольшой резерв).
А если код не замаплен, то опаньки. У нас все же не VMS.
--
dozen @ home
Vladimir Silyaev
>>> ни в одной из них от malloc() null не получил,
>>> при этом поведение они демонстрируют абсолютно разное:
>>> в nbsd получает сильное торможение - но все хоть и медленно но живет;
>>> в linux - отрабатывал oom killer, четко пристрелив именно этот процесс;
>>> в fbsd - получил killed, затем заметил странные вещи - сдохли X
>>> и отвалился pppd, named, и бог знает что еще (maybe rc? don't know)
>>
>> Старая фря у тебя. Новая пристрелит именно этот процесс.
>>
> "very glad" был мой знакомый с фрей к которому я приконнектился для пробы.
> А то что кого-то все равно пристреливают - то что здесь хорошего?
>
> с моей колокольни "very пофигу" выглядел бы так:
> появился ресурс - получи, нет - лежи в свопе / отдыхай / жди, или получай 0,
кто-то освободит память. А ждут они, например, вызове
деструктора, а код онного не был подгружен, и памяти загрузить эту
страницу нету.
> в зависимости от типа своего запроса,
> при этом kernel все свои базовые функции должен гарантировать.
Это какие такие базовые ф-ции, и самое интересное - какие сисколлы
не базовые?
--
Владимир
Vladimir Silyaev
>1) по исчерпанию >90% VM, память нерутовым процессам не дается,
к отстутсвуюшей в памяти странице?
>2) по приближению к критическим границам, процессам дается извещение
>о том, что неплохо бы умерить аппетиты (например, сборку мусора провести),
Ага, только программа которая память пожирает (что-то типа
старого perl'а c for (1..10000000) ), плевала на этот сигнал с
высокой колокольни.
>3) lazy commit исполняется только для тех областей памяти для которых
>он явно заказан,
Ага, а fork он как lazy сommit или precommit? Если fork precommit,
то массы ее не поймут.
>4) нет глупых аппликух которые рассчитаны на тотальный lazy commit,
В таком случае все приложения использующие fork или shared library
глупые. Просто наверное в 99% случаев lazy commit уменьшает потребление
виртуальной (RAM+SWAP) памяти и повышает производительность системы
для реальных програм.
>- было бы получше. Но это уже, увы, целая программа действий, делать
>которые неинтересно.
Вообще-то наверное надежный подход только один - это тотальный
precommit (кстати NT именно так работает). Только такой подход
сильно затормозит систему, на которой работают стандартный
набор программ, что крутится на FreeUnix'ах сегодня.
>Видели же как пишутся, например, куски GNOME?
>Никакое выделение памяти не проверяется на успешность, потому что по
>неуспешном выделении g_new() немедленно хлопает программу.
Так писать проще - потому как написать на C правильные rollback
код это еще та история; и все равно он работать не будет, поскольку
у разработчика никогда не сработает, а вот память он пожирать будет.
>Даже если это большое толстое приложение с расчетом на долгую работу.
>
>И даже при precommit'е есть проблемы.
>Замапили so'шку в память. Поставили в PIC области правильные ссылки.
>Кто должен был сказать что памяти нет? mprotect?
При precommit'е, для всех страниц PIC должно быть зарезервировано
место в VM и чтобы было еще более надежно и все ссылки разрешить
до запуска программы (зачем на проблемы с lazy binding', а?)
>VD> Кроме того, как нетрудно догадаться, лимиты действуют на один
>VD> процесс; при форканье мы шустро движемся в пункт 1 со всеми
>VD> вытекающими.
>VD>
>VD> Я вот чего не пойму -- почему мне не прислать SIGBUS, если я обращаюсь
>VD> к странице, которая не может быть отмаплена по причине недостатка
>VD> памяти? Ведь я ловлю этот сигнал, делаю throw bad_alloc(), раскручиваю
Ага, а код обрабатывающий это throw, сейчас не в памяти (кстати очень
вероятный сценарий) и что делаем - сушим ласты?
--
Владимир
Vladimir Silyaev
файле. Вот и будет свой персональный своп файл, а чтобы процесс
в системе по RSZ не маячил, переодически делать msync и madvise.
--
Владимир
Ilya Anfimov
>>>> Vladimir Dozen wrote:
>
[skipped]
>Вообще, эта проблема _нормально_ не решается IMO нигде, можно получить
>только некоторое приближение к тому, как было бы нормально.
>Где-то числожорка важнее даже init'а ;)), где-то - ее можно рубить каждую
>минуту, а вот sshd надо обеспечить. Если бы было сделано:
>
>1) по исчерпанию >90% VM, память нерутовым процессам не дается,
>2) по приближению к критическим границам, процессам дается извещение
>о том, что неплохо бы умерить аппетиты (например, сборку мусора провести),
>3) lazy commit исполняется только для тех областей памяти для которых
>он явно заказан,
Или я не понял фразу, или lazy commit и так исполняется для тех
областей, для которых явно выставлен copy on write.
>4) нет глупых аппликух которые рассчитаны на тотальный lazy commit,
>
>- было бы получше. Но это уже, увы, целая программа действий, делать
Еще просто необходимо, чтобы для copy on write выделялось
адресное пространство в свопе. Даже не еще а имхо в первую
очередь. Кому это не надо -- пусть отключит, кому надо -- винты
сейчас дешевы.
>которые неинтересно. Видели же как пишутся, например, куски GNOME?
(нет, и видеть не хочу).
>Никакое выделение памяти не проверяется на успешность, потому что по
>неуспешном выделении g_new() немедленно хлопает программу.
>Даже если это большое толстое приложение с расчетом на долгую работу.
>
>И даже при precommit'е есть проблемы.
>Замапили so'шку в память. Поставили в PIC области правильные ссылки.
>Кто должен был сказать что памяти нет? mprotect?
Конечно, он. Какие проблемы?
[skipped]
>VD> Кроме того, как нетрудно догадаться, лимиты действуют на один
>VD> процесс; при форканье мы шустро движемся в пункт 1 со всеми
>VD> вытекающими.
>VD>
>VD> Я вот чего не пойму -- почему мне не прислать SIGBUS, если я обращаюсь
>VD> к странице, которая не может быть отмаплена по причине недостатка
>VD> памяти? Ведь я ловлю этот сигнал, делаю throw bad_alloc(), раскручиваю
>VD> стек и освобождаю кучу памяти -- сам, без помощи какого-то OOM killer!
>
>VD> Парни, может кто сделает патч для linux?
>
>И ты его будешь расставлять на своих машинах?
Он -- будет. Кроме того, есть большая вероятность, что смысл
этого патча поймут люди вроде Кокса и Торвальдса. И вставят в
mainstream.
Я очень нерегулярно и редко читаю lkml. Но когда почитываю, то
неизменно наталкиваюсь на обсуждение этой проблемы.
И виденные мной ответы от местных -- это какое-то непонятный
базар про кривость glibc и крутость линуха.
Подозреваю, что большинство тех, кто может переписать этот кусок
VM просто не понимают о чем речь. А те, кто могут и понимают не
хотят связываться.
>
>
>/netch
Alexander Orlov
AG> проблема может быть в другой софтине, скушавшей много ресурсов.
AG> кроме того данная рекомендация звучит подобно "пишите программы
AG> правильно" :)
И как же писать правильно программы, для неправильно написанных ОС, которые
даже не предупреждают о том, что ресурс исчерпан? Поделись секретом :)
Alexander
Alexander Orlov
AG>> можно после отправки извещения переводить процессы в предсмертное
AG>> состояние, в котором они не могут попросить больше X страниц
AG>> памяти, и по окончании сборки, получив уведомление от процесса,
AG>> переводить их в обычное состояние.
VN> Можно и так.
Да только нафиг не нужно. Сборку мусора, по уму, следует производить без
запроса новой памяти. В крайнем случае, если без этого совсем не обойтись,
надо еще на этапе инициализации процесса запросить у системы резерв под это
дело и хранить его в неприкосновенности до часа Х.
IMO не дело системы разбираться для чего процессу, отожравшему кучу ресурсов,
потребовалось еще что-то отожрать. Раз такой требовательный до ресурсов и
хочешь жить, то выкручивайся сам, а дело системы только предупредить, что
следующий шаг в направлении отжирания ресурса станет для тебя последним.
А вот убивать совсем без предупреждения - это безусловно дурной тон. Это
как у всех светофоров желтую лампочку убрать - жить можно, но хреново :)
Alexander
Serge A. Suchkov
М-м-м ... ну предположим использую я такую фичу (уже лет несколько) ....
Я вот дискуссию на subj евую тему наблюдаю уже в не первой реинкарнации
и никак немогу понять что же хочется то ? Какого то суперразумного поведения
ядра на выверты съехавшего с катушек приложения, пожирающего ресурсы,
или какой то разумной
политики выделения ресурсов для приложений, не закладывающейся на то или
иное поведение ядра ?
ImHO N1(были попытки :)) порядка на 2 сложнее реализовать чем N2(тоже
были попытки.)
BTW: кстати аллокация через mmap вполне рулит но вот принципиально
проблему не решает ImHO.
Она ее отодвигает ...
>
>--
>Владимир
>
--
Serge.
Valentin Nechayev
>> Как? Я над этим уже месяц бьюсь. Предусмотреть размер того,
>> что получится при построении юзером модели, я не могу. Ulimit'ы
>> ненадежны и требуют ручного вмешательства. NULL мне не дают.
>> Signal'ы мне не шлют. Как неродной прям, блин...
VS> Написать свой alloc'атор, который всю память аллоцирует в mmap'ленном
VS> файле. Вот и будет свой персональный своп файл, а чтобы процесс
VS> в системе по RSZ не маячил, переодически делать msync и madvise.
Я сильно сомневаюсь, что это поможет от ушлепывания без предупреждения.
/netch
Valentin Nechayev
>> Кстати, на вопрос, где берутся компьютеры с неограниченными ресурсами,
>> Вы не ответили.;))
AG> машина Тьюринга пойдет? :)))
AG> я не знаю, как ответить на такой вопрос. попробуйте задать его по-другому.
Этот вопрос на самом деле согласно контексту должен был интерпретироваться
как просьба обосновать Ваше предложение не отдавать системе память,
освобожденную процессом, а вместо этого дать системе возможность высвопить
неиспользуемые страницы. В свете данной дискуссии эта просьба не теряет
своей актуальности.;))
/netch
Alexander Gordeyev
> > не нашел способа получить SIGBUS как нотификацию проблем _ядра_.
>
> Это в linux; под hpux я их по собственной глупости ловлю постоянно --
> доступ к невыровненным данным, например.
ну опять же, это проблемы процесса. определенно, SIGBUS не лучший кандидат
в ангела смерти.
> > кстати, если junk pointer - это то, что я думаю, то не SIGSEGV ли должен
> > приходить?
>
> Hу, я SIGSEGV только от *((void*)0) получал, afair.
не верю. да любой невалидный виртуальный адрес, неужели SIGBUS? 8-O
> > ну это звучит разумно. только какая должна быть пауза? а если за этот
> > таймаут
> > процесс еще памяти попросит? а если у него код, который должен отдать
> > память
> > еще не замаплен?
>
> Пауза -- несколько time-slices. Реально этого хватает для вызова
> деструкторов. Hу, скажем, секунда, чтобы с большим запасом. Hе успел --
> все, каюк.
а если я не хочу каюк? если я хочу еще успеть закрыть сетевое соединение и
откинуться по exit и уверен, что деструкторы замаплены?
> Еще памяти не попросит, иначе это дурная программа. (Хотя, строго говоря,
> даже throw Oops(); делает копию объекта, то есть хочет немного памяти,
> так что нужен небольшой резерв).
> А если код не замаплен, то опаньки. У нас все же не VMS.
ну вот видишь, уже не получается стройного и детерминированного механизма. и
это на пальцах. я уверен, что если подумать хорошенько или начать реализовывать
эту схему, то вылезет еще с десяток проблем :(
Alexander Gordeyev
> VN> Можно и так.
> Да только нафиг не нужно. Сборку мусора, по уму, следует производить без
> запроса новой памяти.
ну уже же наткнулись на ситуацию, когда код сборщика в свопе. тогда каюк?
> В крайнем случае, если без этого совсем не обойтись,
> надо еще на этапе инициализации процесса запросить у системы резерв под это
> дело и хранить его в неприкосновенности до часа Х.
хм... вот только сейчас оценил по достоинству механизм выделения памяти в NT.
а ведь это ход конем! введение аналогичного промежуточного состояния страниц
решает все ранее озвученные проблемы!
вот только что случится с fork не соображу навскидку...
> IMO не дело системы разбираться для чего процессу, отожравшему кучу
> ресурсов,
> потребовалось еще что-то отожрать. Раз такой требовательный до ресурсов и
> хочешь жить, то выкручивайся сам, а дело системы только предупредить, что
> следующий шаг в направлении отжирания ресурса станет для тебя последним.
дык _как_ предупредить-то?
Alexander Gordeyev
> AG> я не знаю, как ответить на такой вопрос. попробуйте задать его
> AG> по-другому.
> Этот вопрос на самом деле согласно контексту должен был интерпретироваться
> как просьба обосновать Ваше предложение не отдавать системе память,
> освобожденную процессом, а вместо этого дать системе возможность высвопить
> неиспользуемые страницы.
если мне не изменяет память, в оригинальном письме речь шла о механизме
malloc/free, а не mmap/munmap.
смысл моего сообщения состоял в том, что при написании небольших программ не
следует заморачиваться на тему возможного неэффективного поведения libc или
другой библиотеки, реализующей malloc/free.
в случае же написания систем, частично берущих на себя обязанности ОС или того
же менеджера памяти, отдавать системе неиспользуемую память, разумеется, нужно.
> В свете данной дискуссии эта просьба не теряет своей актуальности.;))
надеюсь на этот раз я внятно изложил свои мысли ;)
Ilya Anfimov
Serge A. Suchkov <s...@e1.bmstu.ru> wrote:
>Vladimir Silyaev wrote:
>
>>On Thu, 9 Aug 2001 19:26:53 +0000 (UTC), Vladimir Dozen wrote:
>>
>>>
>>Написать свой alloc'атор, который всю память аллоцирует в mmap'ленном
>>файле. Вот и будет свой персональный своп файл, а чтобы процесс
>>в системе по RSZ не маячил, переодически делать msync и madvise.
>>
>М-м-м ... ну предположим использую я такую фичу (уже лет несколько) ....
>
>Я вот дискуссию на subj евую тему наблюдаю уже в не первой реинкарнации
>и никак немогу понять что же хочется то ? Какого то суперразумного поведения
>ядра на выверты съехавшего с катушек приложения, пожирающего ресурсы,
Я не буду говорить за всех. Мне хочется очень примитивной вещи:
чтобы при исчерпании памяти у программы просто обламывался mal-
loc(), а не приходил девятый сигнал.
Anatoly A. Orehovsky
Кстати, как удобно было в свое время на FreeBSD "воровать"
память поверх ulimit с помощью своего mmap-аллокатора 8-).
А вставили ли сейчас затычку супротив таких умников ?
Патчик-то уж года два с лишним есть.
--
Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN
http://www.asp-linux.com
Brainbench MVP for Unix Programming
http://www.brainbench.com
Alexander Orlov
AG> хм... вот только сейчас оценил по достоинству механизм выделения
AG> памяти в NT. а ведь это ход конем! введение аналогичного
AG> промежуточного состояния страниц решает все ранее озвученные проблемы!
AG> вот только что случится с fork не соображу навскидку...
fork() при недостатке памяти должен вернуть -1 и установить код ошибки
ENOMEM, malloc() в этом случае должна вернуть NULL. Это согласно манам
и POSIX programmer's guid. Как реально ведет себя fork() в данной ситуации
я не знаю, а malloc потестил - в FreeBSD процесс был убит. Спарашивается,
а какого черта? Почему бы системе не работать в соотвествии с тем, что
декларируется? И не выделять виртуальной памяти больше, чем может
потянуть? Или эти несколько мегабайт "дополнительной" памяти стоят того,
чтобы ради этого пожертвовать надежностью? Получается вообще абсурдная
ситуация - любой процесс в системе может быть молча убит при попытке
получить памяти больше, чем есть в наличии.
Примечательно, что win2000 и MS-DOS работают в полном соотвествии с тем,
что декларируется - под досом мне удалось получить 593 килобайта памяти,
прежде чем malloc вернул NULL, под win2000 566596 килобайт, после чего
malloc опять же вернул NULL. И никаких смертоубийств.
Как все пошло оказалось...
Alexander
Vladimir Dozen
> файле. Вот и будет свой персональный своп файл, а чтобы процесс
> в системе по RSZ не маячил, переодически делать msync и madvise.
... двадцать линуксов, грузящихся по сети. Гиг рамы в каждом.
Типа -- кластер. Диска, вроде, вообще нет(?). Ы?
--
dozen @ home
Vladimir Dozen
>
> не верю. да любой невалидный виртуальный адрес, неужели SIGBUS? 8-O
FreeBSD: *((void*)0xFFFF0000) дал мне именно SIGBUS, afair.
--
dozen @ home
Vladimir Dozen
> Я вот дискуссию на subj евую тему наблюдаю уже в не первой реинкарнации
> и никак немогу понять что же хочется то ? Какого то суперразумного поведения
> ядра на выверты съехавшего с катушек приложения, пожирающего ресурсы,
Кто тебе сказал, что он съехавшее? У него просто работы много.
Клиентов пришло больше, или данные объемистее сегодня (вон,
одни заказчики пытаются анализировать картинки на предмет
нахождения порнографии -- плохому учат ;) -- там ТАКИЕ размеры...
Я ХОЧУ ПОЛУЧИТЬ NULL ОТ MALLOC(). Я ХОЧУ ПОЛУЧИТЬ СИГНАЛ, КОГДА
НЕЛЬЗЯ ОБРАТИТЬСЯ К УЖЕ АЛЛОЦИРОВАННОЙ ПАМЯТИ.
Ну как еще объяснить?
--
dozen @ home
yx
Здесь уже предлагали с такой задачей работать через диск со своим
"приватным своп". В принципе все равно и при этом могут пристрелить,
но зато с гораздо меньшей вероятностью.
Ты кажется смешиваешь несколько, напрямую, не связанных вещей:
получение null от malloc'а и отработку oom killer'a.
Как я это вижу, может я чего здесь неточно понимаю.. посмотрим:
1) null от malloc() при отказе получаешь всегда
note: конечно если процесс к тому времени остается еще живой,
и не пристрелен скажем тем же killer'ом. Иначе - нет процесса,
- нет вопроса "null не дают, сигналы не шлют".
2) oom killer начинает свою стрельбу при исчерпании vm, причем
механизмы выбора жертвы могут быть простыми, как просто первый
попавшийся, так и поизящней - с кучей факторов для выбора жертвы
как в линухе.
Вполне вероятны ситуации, когда толстый процесс, подобный твоему
будет пристрелен oom killer'ом и близко не приближаясь к запросу
на выделение памяти.
Нп простенький пример (maybe fbsd? с ее простым механизмом killer'a):
толстый процесс имеет rss+swap - 10%, и допустим свободно 50% вирт.памяти.
Некто веселый пускает 13 процессов, каждый из которых пусть, скажем по 4%,
захочет отьесть от 50% остатка пирога.
Все, точка X достигнута - вмешивается killer, быстро думает и отстреливает
процесс с максимальным rss+swap - т.е твой, который скорей всего
в это время никого не трогал, чинил примус и вообще память не просил.
При наличии oom killer, гарантия что тебя не пристрелят, только одна
- не быть самым "толстым" с точки зрения того же killer'a, т.к.
о моменте X предварительно публично не оповещается.
Вообщем жертва будет, но - другая, но - она будет.)
Hе быть самым "толстым" для oom killer'a это: или умерить аппетиты, или
постоянно отслеживать чтобы впереди была булка потолще(чужая или своя).
bye.
--
Vladimir Yakovetsky
yx
>> "very glad" был мой знакомый с фрей к которому я приконнектился для пробы.
>> А то что кого-то все равно пристреливают - то что здесь хорошего?
>>
>> с моей колокольни "very пофигу" выглядел бы так:
>> появился ресурс - получи, нет - лежи в свопе / отдыхай / жди, или получай 0,
>
> Ага - вот так и рождается deadlock, когда все процессе ждут когда
> кто-то освободит память. А ждут они, например, вызове
> деструктора, а код онного не был подгружен, и памяти загрузить эту
> страницу нету.
>
Относительно ага и deadlock:
Если такой процесс будет заблокирован (причем даже возможно в виде корки
на диске), и скажем через N периодов требуемую ему память никто
не освободит, тогда(не дождешься) отдать ему тотже 0.
Такая задержка не снимает проблему исчерпания памяти, но даст шанс
обойтись без вмешательства oom killer'a, который разрешает такой узел
слишком моментально и очень кардинально - путем отстрела некоторой жертвы
за счет которой будут жить другие, и не попробовав(не дав)
устаканить ситуацию.
>> в зависимости от типа своего запроса,
>> при этом kernel все свои базовые функции должен гарантировать.
> Это какие такие базовые ф-ции, и самое интересное - какие сисколлы
> не базовые?
>
вообще говоря "very glad/пофигу" относилось к наличию oom killer'a, и
тому что, при этом, os не может гарантировать что процесс, чинящий
примусы и никого не трогающий (но! подпадающий под критерий killer'a)
будет жить. Сию базовую функцию os не исполняет, а причем тут сисколы
я чего-то тоже не пойму.
bye.
--
Vladimir Yakovetsky
yx
если же все не хочешь делать как-то по другому :/
и если тебе интересует только чтобы этого срабатывало в линухе,
то можно предложить вариант, при котором все же oom killer просигнализирует
с SIGTERM - что у тебя `good "badness" и тебя до сих пор не пристрелили
лишь потому что ты особенный(RAWIO)'.
Для этого у процесса должен быть выставлен CAP_SYS_RAWIO.
(Кстати, это единственный вариант когда линуховый oom_killer сигнализирует
своей жертве не SIGKILL'ом ,)))
получится ли что хорошее из этого? не знаю, не знаю..
p.s. для работы с posix/linux capabilities есть libcap библиотечка.
--
Vladimir Yakovetsky
Valentin Nechayev
y> Все, точка X достигнута - вмешивается killer, быстро думает и отстреливает
y> процесс с максимальным rss+swap - т.е твой, который скорей всего
y> в это время никого не трогал, чинил примус и вообще память не просил.
Угу. Мне так однажды сквида убили.
/netch
Valentin Nechayev
AO> а какого черта? Почему бы системе не работать в соотвествии с тем, что
AO> декларируется? И не выделять виртуальной памяти больше, чем может
AO> потянуть? Или эти несколько мегабайт "дополнительной" памяти стоят того,
Потому что расчет на overcommit стал плохой традицией написания приложений.
И потому что с современными VM стало слишком нереально определить
_заранее_ позу впадания в недопустимый overcommit. Потому что есть
допустимый - см. например. cow политику fork'а.
AO> чтобы ради этого пожертвовать надежностью? Получается вообще абсурдная
AO> ситуация - любой процесс в системе может быть молча убит при попытке
AO> получить памяти больше, чем есть в наличии.
Так оно и есть.
Разве что init'а не убивают. Юзайте inittab & daemontools. ;))
AO> Примечательно, что win2000 и MS-DOS работают в полном соотвествии с тем,
AO> что декларируется - под досом мне удалось получить 593 килобайта памяти,
AO> прежде чем malloc вернул NULL, под win2000 566596 килобайт, после чего
AO> malloc опять же вернул NULL. И никаких смертоубийств.
AO> Как все пошло оказалось...
У них fork'а нет. И вместо so'шек dll'ки.
/netch
Alexander Gordeyev
afaYr? ну ладно, ладно, ты меня переленил :)
void main()
{
void *p;
p = mmap(NULL, 0x1000, 0, MAP_PRIVATE|MAP_ANON, -1, 0);
munmap(p, 0x1000);
*(int*)p = 0;
Alexander Gordeyev
> > Ага - вот так и рождается deadlock, когда все процессе ждут когда
> > кто-то освободит память. А ждут они, например, вызове
> > деструктора, а код онного не был подгружен, и памяти загрузить эту
> > страницу нету.
> >
> Относительно ага и deadlock:
> Если такой процесс будет заблокирован (причем даже возможно в виде корки
> на диске), и скажем через N периодов требуемую ему память никто
> не освободит, тогда(не дождешься) отдать ему тотже 0.
какой 0? память уже выделена и не 0. странички не нашлось.
Alexander Gordeyev
> AO> Примечательно, что win2000 и MS-DOS работают в полном соотвествии с тем,
> AO> что декларируется - под досом мне удалось получить 593 килобайта памяти,
> AO> прежде чем malloc вернул NULL, под win2000 566596 килобайт, после чего
> AO> malloc опять же вернул NULL. И никаких смертоубийств.
> AO> Как все пошло оказалось...
>
> У них fork'а нет. И вместо so'шек dll'ки.
а по-подробнее можно? я чего-то ни про fork, ни про so'шки не понял :|
Alexander Gordeyev
> Я ХОЧУ ПОЛУЧИТЬ NULL ОТ MALLOC(). Я ХОЧУ ПОЛУЧИТЬ СИГHАЛ, КОГДА
> HЕЛЬЗЯ ОБРАТИТЬСЯ К УЖЕ АЛЛОЦИРОВАHHОЙ ПАМЯТИ.
а ты уже посмотрел, как эту проблему решают существующие монстры типа GIMP?
yx
>> Если такой процесс будет заблокирован (причем даже возможно в виде корки
>> на диске), и скажем через N периодов требуемую ему память никто
>> не освободит, тогда(не дождешься) отдать ему тотже 0.
>
> какой 0? память уже выделена и не 0. странички не нашлось.
>
можно отстреливаться сигналами, и т.п.. и вернуться на очередной круг
обсуждения полумеры. Понятно одно: и oom killer - плохо, и его
отсутствие (без альт-го подхода) - тоже плохо.. Выхода "прямо и направо"
не наблюдается.. такой вот безобразный факт.
bye.
--
Vladimir Yakovetsky
Valentin Nechayev
SAS> Я вот дискуссию на subj евую тему наблюдаю уже в не первой реинкарнации
SAS> и никак немогу понять что же хочется то ? Какого то суперразумного
SAS> поведения
SAS> ядра на выверты съехавшего с катушек приложения, пожирающего ресурсы,
SAS> или какой то разумной
SAS> политики выделения ресурсов для приложений, не закладывающейся на то или
SAS> иное поведение ядра ?
SAS> ImHO N1(были попытки :)) порядка на 2 сложнее реализовать чем N2(тоже
SAS> были попытки.)
Суперразумного поведения не требуется. Не задача ядра думать "вот этому
можно еще 100К, потому что он хороший, просто надо тут перепаковать и ужать",
пусть само приложение крутится. Задача ядра - сказать заранее "ребята,
становится тесно", ну и аккуратно свистнуть "ну нету тебе памяти"
прежде чем ее не станет всем.
В свете упоминаний про "состояния страниц в NT" подумалось - раз есть
все равно COW и прочие автоматические выделения памяти, то почему бы не
дать возможность приложению резервировать память под эти цели, и не управлять
этим резервом? Типа "дай мне мег под lazy commit'ы и дай SIGBUS когда
там останется 256K".
SAS> BTW: кстати аллокация через mmap вполне рулит но вот принципиально
SAS> проблему не решает ImHO.
SAS> Она ее отодвигает ...
Аллокация через mmap в принципе дает только одно - вместо куска резины,
который можно тянуть больше, можно меньше, но все равно это _один_ кусок -
появляется возможность иметь много маленьких кусочков и возвращать
их по мере освобождения. Собственно проблему кризиса памяти оно действительно
не решает.
/netch
Valentin Nechayev
>> AO> Примечательно, что win2000 и MS-DOS работают в полном соотвествии с тем,
>> AO> что декларируется - под досом мне удалось получить 593 килобайта памяти,
>> AO> прежде чем malloc вернул NULL, под win2000 566596 килобайт, после чего
>> AO> malloc опять же вернул NULL. И никаких смертоубийств.
>> AO> Как все пошло оказалось...
>> У них fork'а нет. И вместо so'шек dll'ки.
AG> а по-подробнее можно? я чего-то ни про fork, ни про so'шки не понял :|
fork реализуется с минимумом крови через COW, а это приводит к тому,
что как минимум одно место, где COW вот так сразу и висит дамокловым
мечом, уже есть. Сразу для него заводить место в свопе - конечно,
красиво, но для многих случаев слишком нереально. Вот крутится 100 апачей.
У них по 10M общих страниц и по 5М своих версий. Надо будет резервировать
на них гиг свопа? Я боюсь, что пошлют с такими запросами далеко-далеко ;|
У so'шек проблема - что их вначале мапят, потом начинают relocations.
Причем, если so'шка сделана в соответствии с традициями - сгенерирован
PIC code - то основная часть кода не меняется и получается общей на все
процессы. Можно и не делать для so'шки PIC code, это будет работать быстрее
(на пару процентов для простых либ, на 30% для libperl, согласно
vi...@ice.ru), но тогда будет потеря памяти, которая опять же для стабильной
ситуации в системе будет слишком неоправданной.
Несколько суммируя - разные COW настолько экономят ресурсы и настолько
въелись в нынешнюю практику, что надо или предложить что-то значительно
более выгодное, или пытаться работать, не попадая под безусловный
SIGKILL, с учетом этого фактора...
/netch
Alexander Gordeyev
> В свете упоминаний про "состояния страниц в NT" подумалось - раз есть
> все равно COW и прочие автоматические выделения памяти, то почему бы не
> дать возможность приложению резервировать память под эти цели, и не управлять
> этим резервом? Типа "дай мне мег под lazy commit'ы и дай SIGBUS когда
> там останется 256K".
не получается. если в системе кончилась память, но приложение еще не достигло
заказанного лимита в 256К, то для него складывается существующая сейчас
ситуация.
т.о. заказ памяти под lazy commit'ы не имеет смысла, если ОС не гарантирует,
что сможет найти страницу по PF.
если же ОС гарантирует страницу для lazy-commit-региона, то заказывать остаток
тоже бессмысленно, поскольку обламывать нужно сразу при выделении региона.
ps. в-общем, после проникновения в проблему COW/fork, я понял _как_ все плохо.
Serge A. Suchkov
>ehlo.
>
>>Я вот дискуссию на subj евую тему наблюдаю уже в не первой реинкарнации
>>и никак немогу понять что же хочется то ? Какого то суперразумного поведения
>>ядра на выверты съехавшего с катушек приложения, пожирающего ресурсы,
>>
>
> Кто тебе сказал, что он съехавшее? У него просто работы много.
> Клиентов пришло больше, или данные объемистее сегодня (вон,
> одни заказчики пытаются анализировать картинки на предмет
> нахождения порнографии -- плохому учат ;) -- там ТАКИЕ размеры...
>
> Я ХОЧУ ПОЛУЧИТЬ NULL ОТ MALLOC()
>
про "никак" в фрюниксах вроде бы уже сказали ...
про то как можно:
1) повторюсь, аллокация через mmap, но это ,как сам понимаешь, ни разу
ни malloc
2) написать собственный механизм работы с пулом с предварительно
malloc+commit
некоего большого кусока памяти и собственно работа с этим куском через
свой собственный механизм работы с пулом - НО всегда остается риск что
таки найдется другой процесс
который захочет таки поиметь памяти, и кого грохнет OOM killer в данном
случае - это вопрос.
3) ulimit - НО в системах завязаных на fork-модель обработки данных он
ImHO малоэффективен (т.е. вроде бы
не критическое число копий процесса с вроде бы некритическим SIZE/RSS
легко его обходят)
>. Я ХОЧУ ПОЛУЧИТЬ СИГНАЛ, КОГДА
> НЕЛЬЗЯ ОБРАТИТЬСЯ К УЖЕ АЛЛОЦИРОВАННОЙ ПАМЯТИ.
>
А разве процесс не получает SIGTERM ?
>
--
Serge.
Serge A. Suchkov
1) NFS
2) А что за кластер ? Могет у него есть собственный механизм работы с
памятью (Network RAM) ?
>
>
--
Serge.
Valentin Nechayev
> > В свете упоминаний про "состояния страниц в NT" подумалось - раз есть
> > все равно COW и прочие автоматические выделения памяти, то почему бы не
> > дать возможность приложению резервировать память под эти цели,
> > и не управлять
> > этим резервом? Типа "дай мне мег под lazy commit'ы и дай SIGBUS когда
> > там останется 256K".
> не получается. если в системе кончилась память, но приложение еще не достигло
> заказанного лимита в 256К, то для него складывается существующая сейчас
> ситуация.
Это если сразу будут SIGKILL'ы раздаваться.
А если хоть какое-то демпфирование - то можно будет еще успеть
освободить сколько получится, когда придет нотификация.
> т.о. заказ памяти под lazy commit'ы не имеет смысла, если ОС не гарантирует,
> что сможет найти страницу по PF.
А как она не найдет страницу, если я ее заказал заранее? ;))
> если же ОС гарантирует страницу для lazy-commit-региона, то заказывать остаток
> тоже бессмысленно, поскольку обламывать нужно сразу при выделении региона.
Обламывать заранее при расчете на lazy commit бессмысленно.
Кто-то закажет гиг под разреженный массив, а из него заюзает пару метров.
> ps. в-общем, после проникновения в проблему COW/fork, я понял _как_ все плохо.
Ну не так все и страшно. IMO. Просто надо выйти из шарахания в крайность.
Тотальный прекоммит был одной крайностью. Тотальный lazy commit
и срубание всех вокруг чтобы расчистить жизненное пространство -
другая крайность.
/netch
Alexander Gordeyev
> > т.о. заказ памяти под lazy commit'ы не имеет смысла, если ОС не
> > гарантирует,
> > что сможет найти страницу по PF.
> А как она не найдет страницу, если я ее заказал заранее? ;))
mmap по идее и есть "заказать заранее". однако ж опаньки.
> > если же ОС гарантирует страницу для lazy-commit-региона, то заказывать
> остаток
> > тоже бессмысленно, поскольку обламывать нужно сразу при выделении региона.
>
> Обламывать заранее при расчете на lazy commit бессмысленно.
> Кто-то закажет гиг под разреженный массив, а из него заюзает пару метров.
1. об обломе.
ну смотри. заказываем гиг под разреженный массив. юзаем пару метров. остальное
не используется, но при необходимости _гарантированно_ предоставляется.
какие в этом случае могут быть причины для облома выделения lazy commit-
региона(LCR)? только одна - ОС не может/хочет _в момент выделения_
предоставить ресурсы.
а как можно обломать приложение не "заранее", а немного спустя, когда уже
продекларировано, что страницы для LCR по PF гарантированы? не понимаю.
т.о. в предложенной тобой схеме получается, что обламывать нужно сразу или
никогда.
2. об остатке.
ок, ресурсы нашлись, регион выделился, страницы при PF по этим адресам _всегда_
найдутся. вопрос - зачем приложению знать, что осталось 256К? два варианта...
если в системе ресурсов недостаточно, то какая разница, заказало приложение
нотификацию по остатку 256К или 512К, схлопываться-то по-любому надо. а сборку
мусора проводить поздно - сборка мусора должна осуществляться постоянно.
соответственно вся память, что есть у приложения ему на текущий момент нужна,
и все, что остается - это корректно завершиться/рестартовать.
если же в системе достаточно ресурсов, зачем приложению вообще знать об
остатке? схлопываться не надо, мусор собирать - тоже. поднимет свои 256К и
еще попросит.
Valentin Nechayev
> > > т.о. заказ памяти под lazy commit'ы не имеет смысла, если ОС не
> > > гарантирует,
> > > что сможет найти страницу по PF.
> > А как она не найдет страницу, если я ее заказал заранее? ;))
> mmap по идее и есть "заказать заранее". однако ж опаньки.
mmap вообще-то есть всего лишь назначение чего-то на кусок адресного
пространства. Изначально - находящегося на диске файла.;)
Выделение произвольной памяти через него - уже совсем другой эффект,
появившийся, как я понял, как побочный - за счет простой идеи обобщения
механизма.
> > Обламывать заранее при расчете на lazy commit бессмысленно.
> > Кто-то закажет гиг под разреженный массив, а из него заюзает пару метров.
> 1. об обломе.
> ну смотри. заказываем гиг под разреженный массив. юзаем пару метров. остальное
> не используется, но при необходимости _гарантированно_ предоставляется.
> какие в этом случае могут быть причины для облома выделения lazy commit-
> региона(LCR)? только одна - ОС не может/хочет _в момент выделения_
> предоставить ресурсы.
> а как можно обломать приложение не "заранее", а немного спустя, когда уже
> продекларировано, что страницы для LCR по PF гарантированы? не понимаю.
Послав сигнал. Заранее, а не тогда, когда уже поздно.
Фактически, нехватка памяти уже при использовании является асинхронным
событием, а об асинхронном событии принято извещать сигналом.
Тот страничный резерв, о котором я говорю - средство известить заранее,
и не более того.
> т.о. в предложенной тобой схеме получается, что обламывать нужно сразу или
> никогда.
Нет. Ничего такого моя схема не содержит.
Можно заказать гиг, но гарантированного пула запросить мег.
А в обработчике SIGBUS попросить еще. И если не дадут - поставить флаг,
сказать longjmp(), или еще как-то вылететь из выжирательного процесса
вовремя, пока еще нехватка не стала фатальной.
А кто хочет зарезервировать кусок VM сразу - пожалуйста, и это можно.
Но не рекомендуется (включая лимиты).
> 2. об остатке.
>
> ок, ресурсы нашлись, регион выделился, страницы при PF по этим
> адресам _всегда_
> найдутся. вопрос - зачем приложению знать, что осталось 256К? два варианта...
Ну так Вы не поняли что за схему я предложил. Оттого и этот вопрос.
> если в системе ресурсов недостаточно, то какая разница, заказало приложение
> нотификацию по остатку 256К или 512К, схлопываться-то по-любому надо.
> а сборку
> мусора проводить поздно - сборка мусора должна осуществляться постоянно.
Механизмы сборки мусора бывают слишком разные.
Оно конечно хорошо сказать "сборка мусора должна осуществляться постоянно" -
только вот emacs, например, содержит ужасно примитивный вариант оного.
/netch
Eugene Grosbein
nsku> Hу не так все и страшно. IMO. Просто надо выйти из шарахания в
nsku> крайность.
nsku> Тотальный прекоммит был одной крайностью.
Кстати, во FreeBSD оно таки есть и per process, если можно так выразиться ;)
Eugene
Alexander Gordeyev
> > а как можно обломать приложение не "заранее", а немного спустя, когда уже
> > продекларировано, что страницы для LCR по PF гарантированы? не понимаю.
>
> Послав сигнал. Заранее, а не тогда, когда уже поздно.
> Фактически, нехватка памяти уже при использовании является асинхронным
> событием, а об асинхронном событии принято извещать сигналом.
или kevent'ом? ;))))
> Hу так Вы не поняли что за схему я предложил. Оттого и этот вопрос.
угу, видимо так :(
ладно, это надо либо устно обсуждать, либо пропозлы публиковать, а так уже на
круг уйти можем.
Vladimir Dozen
> > Типа -- кластер. Диска, вроде, вообще нет(?). Ы?
> 1) NFS
Ну, может быть, но некузяво как-то. Свопинг по NFS -- байтораздирающее
зрелище, да и чтобы страничку в своп отправить, тоже, вероятно, память
нужна -- буфера?
> 2) А что за кластер ? Могет у него есть собственный механизм работы с
> памятью (Network RAM) ?
Да не, это рукотворный. Кучка CORBA-серверов и один master, раздающий
им задания.
--
dozen @ home
Vladimir Dozen
> 1) null от malloc() при отказе получаешь всегда
??? Если бы. Еще раз:
char* p = new char[128*1024*1024];
memset(p,0,128*1024*1024);
malloc() возвращает честный указатель. Процесс умирает
на memset().
> 2) oom killer начинает свою стрельбу при исчерпании vm, причем
> механизмы выбора жертвы могут быть простыми, как просто первый
> попавшийся, так и поизящней - с кучей факторов для выбора жертвы
> как в линухе.
Это -- изящество? Можно обвешать OOMK каким угодно количеством
"свистелок и перделок", изображающих интеллект, но его тупого
солдафонства не скрыть. Resistance is futile, а переговоры
бессмысленны -- враг будет уничтожен. Я только не пойму, почему
же это я враг?
> При наличии oom killer, гарантия что тебя не пристрелят, только одна
> - не быть самым "толстым" с точки зрения того же killer'a, т.к.
Иначе говоря, "кто не работает, тот не умирает". ;/
--
dozen @ home
Vladimir Dozen
> 1) повторюсь, аллокация через mmap, но это ,как сам понимаешь, ни разу
> ни malloc
Я это потестирую, но, сдается мне, получу я тот же SIGKILL когда
система не сможет отмапить мою очередную страницу...
> 2) написать собственный механизм работы с пулом с предварительно
> malloc+commit
> некоего большого кусока памяти и собственно работа с этим куском через
> свой собственный механизм работы с пулом
Вот и убъют тебя на коммите. Так здесь принято. :(
> >. Я ХОЧУ ПОЛУЧИТЬ СИГНАЛ, КОГДА
> > НЕЛЬЗЯ ОБРАТИТЬСЯ К УЖЕ АЛЛОЦИРОВАННОЙ ПАМЯТИ.
>
> А разве процесс не получает SIGTERM ?
Иэээх. Если бы. SIGKILL. Даже если бы SIGTERM -- как мне различить
system shutdown и not enough memory? При первом я должен чисто и быстро
выйти, при втором -- всего лишь откатить текущий процессинг...
--
dozen @ home
Vladimir Dozen
>
> afaYr? ну ладно, ладно, ты меня переленил :)
Проверил -- да, SIGBUS.
> void main()
> {
> void *p;
> p = mmap(NULL, 0x1000, 0, MAP_PRIVATE|MAP_ANON, -1, 0);
> munmap(p, 0x1000);
> *(int*)p = 0;
> }
FreeBSD: SIGSEGV.
Возвращаясь к теме: да неважно, на самом деле, какой сигнал будет
приходить, лишь бы приложение могло отличить его от прочих
событий. Есть же SIGXCPU и SIGXFSZ, почему нет SIGXMEM?
Дефолтовый обработчик -- снос приложения.
Лично я поддерживаю идею Нечаева о некоем НЗ-пуле страниц для
каждого(?) процесса, и приходе сигнала, когда выделить страницу
неоткуда, кроме как из этого пула (2VN: я правильно понял?).
Вопрос в интерфейсе -- какие процессы должны иметь пул и каков
должен быть его размер. "Какие" -- это, видимо, довольно просто --
если приложение регистрирует обработчик SIGXMEM (вариант -- SIGBUS),
то ему нужен пул.
Вот с размером сложнее, он зависит от технологии
отката, используемой в приложении. Скажем, в плюсовом приложнии
в минимальном варианте throw вообще не ест памяти (если бросать
заранее созданный глобальный статический объект), либо требует
минимума памяти (std::exception и наследники с запасом поместятся в
4K-страницу). В более сложных вариантах может потребоваться создание
каких-то объектов (например, LoggerRecord()). Предсказать размер
не представляется возможным, так что процесс должен сам сказать,
сколько памяти ему нужно для отката. Как? Можно добавить константу в
setrlimit: setrlimit(RLIMIT_POOL,...), хотя это выносит подробности
функционирования системы на уровень, который должен (потенциально)
быть переносимым. Можно ввести специальный сисколл. Можно использовать
default в пару десятков страниц, и использовать значение из переменной
среды, if available. Еще идеи?
Лично я думаю, что подобный механизм гораздо лучше тупого OOMK,
и операционка, его имеющая, выиграет в надежности.
Comments?
--
dozen @ home
Serge A. Suchkov
>>> ... двадцать линуксов, грузящихся по сети. Гиг рамы в каждом.
>>> Типа -- кластер. Диска, вроде, вообще нет(?). Ы?
>>>
>
>>1) NFS
>>
>
> Ну, может быть, но некузяво как-то. Свопинг по NFS -- байтораздирающее
> зрелище, да и чтобы страничку в своп отправить, тоже, вероятно, память
> нужна -- буфера
>
Буфера разумеется нужны - как сей механизм поведет себя при
массированном свопинге
вообще говоря ХЗ - НО некоторые мои эксперименты в этом направлении
вроде бы каких
то проблем с памятью не вызывали ...
собственно тестовая задачка заключалась в сортировке некоторого большого
файла
~100Mb как отмапленного куска памяти (памяти в машине было 64ram+128swap)
... если конечно не считать проблемой просадку производительности из за
непрерывного свопинга ...
--
Serge.
yx
>> 1) null от malloc() при отказе получаешь всегда
>
> ??? Если бы. Еще раз:
>
> char* p = new char[128*1024*1024];
> memset(p,0,128*1024*1024);
>
> malloc() возвращает честный указатель. Процесс умирает
> на memset().
>
malloc() отработал, commit не прошел, граблемы не к malloc() адресованы.
можешь ловить(в линух) по жел. и sigterm, в случае fbsd не знаю
(но вполне вероятно при таком твоем запросе пристрелят кого-то левого,
и ты свою память отюзаешь - так и не с кем не свидившись "в Самарре" ,))
ы ты этого хотел? (ты ведь не враг, в отличии от других процессов) ?))
>> 2) oom killer начинает свою стрельбу при исчерпании vm, причем
>> механизмы выбора жертвы могут быть простыми, как просто первый
>> попавшийся, так и поизящней - с кучей факторов для выбора жертвы
>> как в линухе.
>
> Это -- изящество? Можно обвешать OOMK каким угодно количеством
> "свистелок и перделок", изображающих интеллект, но его тупого
> солдафонства не скрыть. Resistance is futile, а переговоры
> бессмысленны -- враг будет уничтожен. Я только не пойму, почему
> же это я враг?
>
>> При наличии oom killer, гарантия что тебя не пристрелят, только одна
>> - не быть самым "толстым" с точки зрения того же killer'a, т.к.
>
> Иначе говоря, "кто не работает, тот не умирает". ;/
>
нормально "кто долго и упорно крутился" отстрелен вряд ли будет -
это один из "солдафонских" факторов при определении `толщины'
в oom killer'e.
Кто хочет "сразу и больше чем все" тому действительно лучше "не работать"
- пристрелят, если не скажешь конечно - "я бессмертный" киллеру.))
Если же не нравится используемая oom стратегия - ставь пустую заглушку
на место 00M, или грузи свой стратегически верный oom killer (какой он должен
быть - я не представляю, все что здесь обсуждали - полумеры imho).
Благо для тебя, даже соотв. патч (oomk - в виде модуля) есть в случае линуха,
чтобы и ты смог потестировать с комфортом свой кульный oom antireviver.
p.s. мне тоже не нравится идея заложенная в oom killer,
но ведь !приемлего решения не видно, и по. приходится иногда обходить oom.
bye.
--
Vladimir Yakovetsky
Vladimir Dozen
> можешь ловить(в линух) по жел. и sigterm
Приходит SIGKILL, который при всем желании не поймать.
> Благо для тебя, даже соотв. патч (oomk - в виде модуля) есть в случае линуха,
> чтобы и ты смог потестировать с комфортом свой кульный oom antireviver.
А для моих кастомеров? И вообще для произвольно взятого дистрибутива?
Почему я должен патчить все, что движется, для достижения хоть
сколько-нибудь приемлимой надежности?
--
dozen @ home
yx
>> можешь ловить(в линух) по жел. и sigterm
>
> Приходит SIGKILL, который при всем желании не поймать.
>
что такое capability в linux'е (posix.1e, std25.2) знаешь?
Если знаешь, и у тебя такая неординарная ситуация - что надо vm исчерпывать,
тогда прикинься что с железкой работаешь (выст. cap_sys_rawio),
и ожидай sigterm - если oomk решит что ты еще тот (правда у тебя и так
приоритет на отстрел знач-но(/=4) уменьшится, то если и прижмет vm -
получишь только sigterm, но никак не 9-ку. Дальше ситуация зависит от твоей
задачи, если немного облегчишься - все нормально, если нет - системе будет
туго, но я думаю выживет (за счет других).
>> Благо для тебя, даже соотв. патч (oomk - в виде модуля) есть в случае линуха,
>> чтобы и ты смог потестировать с комфортом свой кульный oom antireviver.
>
> А для моих кастомеров? И вообще для произвольно взятого дистрибутива?
> Почему я должен патчить все, что движется, для достижения хоть
> сколько-нибудь приемлимой надежности?
>
подход к задаче менять не хочешь, ранее спрашивал о патчах,
вот и соотв-й предлог у меня получился. ("Шура! Вы зануда" :)
все что только можно ожидать в так.ситуации - уже предлагали,
чего еще ожидать то?
- самодовлеющую систему, разрабатывавшуюся под конкретную задачу,
и настолько определенную, что практически бесполезную, даа-а?
bye.
--
Vladimir Yakovetsky
Vladimir Silyaev
>> 1) повторюсь, аллокация через mmap, но это ,как сам понимаешь, ни разу
>> ни malloc
>
> Я это потестирую, но, сдается мне, получу я тот же SIGKILL когда
> система не сможет отмапить мою очередную страницу...
А SIGKILL раздается не тогда, когда не хватает физической памяти,
а когда кончается виртуальная память (RAW+swap). В случае же
когда куча(heap) находится на mmap'ленном файле размер виртуальной
памяти доступной системе увеличивается на размер такой кучи.
>> 2) написать собственный механизм работы с пулом с предварительно
>> malloc+commit
>> некоего большого кусока памяти и собственно работа с этим куском через
>> свой собственный механизм работы с пулом
>
> Вот и убъют тебя на коммите. Так здесь принято. :(
Ты не понял, коммит делается непосредственно после запуска програмы,
а в процессе работы программа от системы ничего больше не просит.
--
Владимир
Vladimir Silyaev
> Лично я поддерживаю идею Нечаева о некоем НЗ-пуле страниц для
> каждого(?) процесса, и приходе сигнала, когда выделить страницу
> неоткуда, кроме как из этого пула (2VN: я правильно понял?).
> Вопрос в интерфейсе -- какие процессы должны иметь пул и каков
> должен быть его размер. "Какие" -- это, видимо, довольно просто --
> если приложение регистрирует обработчик SIGXMEM (вариант -- SIGBUS),
> то ему нужен пул.
>
> Вот с размером сложнее, он зависит от технологии
> отката, используемой в приложении. Скажем, в плюсовом приложнии
> в минимальном варианте throw вообще не ест памяти (если бросать
> заранее созданный глобальный статический объект), либо требует
> минимума памяти (std::exception и наследники с запасом поместятся в
> 4K-страницу). В более сложных вариантах может потребоваться создание
> каких-то объектов (например, LoggerRecord()). Предсказать размер
> не представляется возможным, так что процесс должен сам сказать,
> сколько памяти ему нужно для отката. Как? Можно добавить константу в
> setrlimit: setrlimit(RLIMIT_POOL,...), хотя это выносит подробности
> функционирования системы на уровень, который должен (потенциально)
> быть переносимым. Можно ввести специальный сисколл. Можно использовать
> default в пару десятков страниц, и использовать значение из переменной
> среды, if available. Еще идеи?
>
> Лично я думаю, что подобный механизм гораздо лучше тупого OOMK,
> и операционка, его имеющая, выиграет в надежности.
В надежности чего?
Вариантов устроить DOS если могут запускаться какие угодно программы,
и так не мало. А DOS с отьеданием виртуальной памяти лечится через
limits.
А обсуждаемая проблема imho, не стоит и въеденного яйца, все что
нужно делать если в системе кончилось место в своп'е - это:
- проверить, на наличие диких процессов отъевших память, если
таковый есть, то поставить limits на память и кол-во процессов для этого uid
- если все процессы правильные, добавить свопа.
Вторую часть можно и автоматизировать, если есть такое желание.
--
Владимир
P.S. В простейшем случае в своей программе можно периодически проверять
размер свободного места в свопе, и если оно стремится к нулю, плавно
умерить аппетиты в памяти, и/или спокойно склеить ласты.
Vladimir Silyaev
>собственно тестовая задачка заключалась в сортировке некоторого большого
>файла
>~100Mb как отмапленного куска памяти (памяти в машине было 64ram+128swap)
>... если конечно не считать проблемой просадку производительности из за
>непрерывного свопинга ...
используются другие методы сортировки, т.н. метод слияния.
А сортировать втупую 100MB файл в 64MB ram, просто бессмысленно, из-за
большого количества проходов по файли, и как следствие частого
обращения к разным страницам, любой механизм свопа будет бесполезен.
--
Владимир
Valentin Nechayev
VNS> А, на $@#$, если это все равно никто использовать не будет.
Если ввести тайком - то да.
Если сделать нормально - разные гномы, которые ничего кроме как схлопнуться
не умеют, пусть себе хлопаются. Нормальный софт, рассчитанный на то,
чтобы сделать свое дело и выжить в ограниченных ресурсах - будет использовать,
пусть даже эти механизмы будут специфичными для одной отдельно взятой
платформы.
VNS> А обсуждаемая проблема imho, не стоит и въеденного яйца, все что
VNS> нужно делать если в системе кончилось место в своп'е - это:
VNS> - проверить, на наличие диких процессов отъевших память, если
VNS> таковый есть, то поставить limits на память и
VNS> кол-во процессов для этого uid
VNS> - если все процессы правильные, добавить свопа.
Ага, ага. Задним числом, когда уже пристрелили то, что должно жить?
А если sshd пристрелят?
VNS> Вторую часть можно и автоматизировать, если есть такое желание.
Угу. И повторяя до бесконечности. И 20*RAM выжрут, и 100*RAM.
Медленнее, но выжрут. Прожорливость - она штука постоянная.
Все живое старается размножиться до тех пор пока не начнет мереть
от голоду. И человечество не исключение, и псевдожизнь в виде процессов
в компьютере.
VNS> P.S. В простейшем случае в своей программе можно периодически проверять
VNS> размер свободного места в свопе, и если оно стремится к нулю, плавно
VNS> умерить аппетиты в памяти, и/или спокойно склеить ласты.
Race condition в чистом виде, однако.
/netch
Valentin Nechayev
>>~100Mb как отмапленного куска памяти (памяти в машине было 64ram+128swap)
>>... если конечно не считать проблемой просадку производительности из за
VNS> >непрерывного свопинга ...
VNS> Это уже оффтопик, но когда объем файла превышает размер памяти, то
VNS> используются другие методы сортировки, т.н. метод слияния.
VNS> А сортировать втупую 100MB файл в 64MB ram, просто бессмысленно, из-за
VNS> большого количества проходов по файли, и как следствие частого
VNS> обращения к разным страницам, любой механизм свопа будет бесполезен.
Что значит бесполезен? Не будет работать? Или будет хуже работать?
Насколько хуже?
При сортировке массива указателей - пожалуй, будет тормозить.
И то еще надвое сказано.
Если же линейный массив объектов, а сортировка стандартная Хоара - уже
будет не так - будут последовательности линейных движений по массиву,
под которые VM неплохо оптимизирует свое поведение.
/netch
Valentin Nechayev
> А SIGKILL раздается не тогда, когда не хватает физической памяти,
> а когда кончается виртуальная память (RAW+swap). В случае же
> когда куча(heap) находится на mmap'ленном файле размер виртуальной
> памяти доступной системе увеличивается на размер такой кучи.
Случай применения mmap("/dev/zero") как механизм выделения памяти Вам
совершенно незнаком? В этом случае занимается своп, а не диск.
> >> 2) написать собственный механизм работы с пулом с предварительно
> >> malloc+commit
> >> некоего большого кусока памяти и собственно работа с этим куском через
> >> свой собственный механизм работы с пулом
> > Вот и убъют тебя на коммите. Так здесь принято. :(
> Ты не понял, коммит делается непосредственно после запуска програмы,
> а в процессе работы программа от системы ничего больше не просит.
У программы все равно есть собственная незамапленная на файл память.
Значит, ее могут за это убить.
/netch
Vladimir Dozen
> Если знаешь, и у тебя такая неординарная ситуация - что надо vm исчерпывать,
> тогда прикинься что с железкой работаешь (выст. cap_sys_rawio),
> и ожидай sigterm - если oomk решит что ты еще тот (правда у тебя и так
Да понял я все про капабилитис, уже в TODO внес, только вот ...
как мне различить system shutdown (пришел sigterm) и OOMK (пришел
sigterm)? По каким-то внешним проявлениям? Криво.
--
dozen @ home
Vladimir Dozen
> > А для моих кастомеров? И вообще для произвольно взятого дистрибутива?
> > Почему я должен патчить все, что движется, для достижения хоть
> > сколько-нибудь приемлимой надежности?
> подход к задаче менять не хочешь, ранее спрашивал о патчах,
Э... ты я вполне последователен -- я спрашивал: "может КТО-НИБУДЬ
патч напишет?", а ты говоришь: "напиши САМ". Совсем разные вещи,
не так ли? ;) ;(
Нет у меня времени патчи писать (может, оно и к лучшему для Linux'а ;).
--
dozen @ home
Vladimir Dozen
>
> А SIGKILL раздается не тогда, когда не хватает физической памяти,
> а когда кончается виртуальная память (RAW+swap). В случае же
> когда куча(heap) находится на mmap'ленном файле размер виртуальной
> памяти доступной системе увеличивается на размер такой кучи.
Был неправ, буду тестировать.
--
dozen @ home
Vladimir Dozen
> нужно делать если в системе кончилось место в своп'е - это:
> - проверить, на наличие диких процессов отъевших память, если
> таковый есть, то поставить limits на память и кол-во процессов для этого uid
> - если все процессы правильные, добавить свопа.
Ты мыслишь категориями inet-админа. Для него пару раз уронить какой-то
сервис -- не беда, все сервисы -- stateless (httpd,...), клиент
переконектится и попрет дальше. Для _таких_ сервисов OOMK вполне нормален --
{x}inetd/папа/RunCache.sh перезапустит, да и дело с концом.
А вот если процесс к моменту OOM имеет массу полезной информации, которую
он уже сутки обсчитывал, то любой снос или итеративный подбор размеров
свопа воспринимается ... с неодобрением.
Аналогия, чтоб ты понял чувства: представь, что ты собираешь ядро, и
вот, в самом конце, линкер говорит тебе: "ой, мы тут на слишком маленький
размер стека заложились, ща мы его значение увеличим, и пересоберем
с самого начала". И так 15 раз.
--
dozen @ home
Vladimir Dozen
> >> некоего большого кусока памяти и собственно работа с этим куском через
> >> свой собственный механизм работы с пулом
> >
> > Вот и убъют тебя на коммите. Так здесь принято. :(
> Ты не понял, коммит делается непосредственно после запуска програмы,
> а в процессе работы программа от системы ничего больше не просит.
Во-первых, откуда мне знать, сколько захочет следующий клиент,
во-вторых, какоя для системы разница, прошу я 2G сразу после старта
или через сутки? Все равно столько нету, и все равно на доступе получу
убиение.
--
dozen @ home
Serge A. Suchkov
При старте процесса отфоркай следилку ...
если в некий момент времени пятнашку получает и следилка и сам рабочий
процесс
то она раздавалась по -1 (всем) - это шутдаун
- если SIGTERM получает только рабочий процесс - это subjевый случай
а то что криво эт да :))
>
--
Serge.
Valentin Nechayev
> > Да понял я все про капабилитис, уже в TODO внес, только вот ...
> > как мне различить system shutdown (пришел sigterm) и OOMK (пришел
> > sigterm)? По каким-то внешним проявлениям? Криво.
> При старте процесса отфоркай следилку ...
> если в некий момент времени пятнашку получает и следилка и сам рабочий
> процесс
> то она раздавалась по -1 (всем) - это шутдаун
> - если SIGTERM получает только рабочий процесс - это subjевый случай
IMO это просто не будет работать, потому что если системе плохо,
то процессы получат управление с сильным разрывом по времени и
сговориться, что это было и почему, они просто не успеют...
/netch
Valentin Nechayev
> Возвращаясь к теме: да неважно, на самом деле, какой сигнал будет
> приходить, лишь бы приложение могло отличить его от прочих
> событий. Есть же SIGXCPU и SIGXFSZ, почему нет SIGXMEM?
> Дефолтовый обработчик -- снос приложения.
>
> Лично я поддерживаю идею Нечаева о некоем НЗ-пуле страниц для
> каждого(?) процесса, и приходе сигнала, когда выделить страницу
> неоткуда, кроме как из этого пула (2VN: я правильно понял?).
Примерно. Ваша интерпретация даже лучше первоначальной идеи.
> Вопрос в интерфейсе -- какие процессы должны иметь пул и каков
> должен быть его размер. "Какие" -- это, видимо, довольно просто --
> если приложение регистрирует обработчик SIGXMEM (вариант -- SIGBUS),
> то ему нужен пул.
Я бы сделал не так. Кому нужен такой пул - тот явно его закажет явным запросом.
Вопли типа "нефиг лишние сисколлы разводить" идут, естественно, нафиг.
Требуется: узнавание текущего размера; задание желаемого (может обвалиться);
задание границы для генерации сигнала. Также узнавание (без плясок с бубном
над procfs): сколько VM всего у процесса, сколько private, сколько shared
(включая cow), сколько uncommitted. Также команду сделать заданное количество
(и место) cow памяти личной.
Кому все это не нужно - будет максимум шарить и дохнуть по сигналу при попытке
коммита. Кому нужно - будет страховаться.
Заметим, что это вопрос во чем-то ортогональный тому, что делает
система при переполнении общего пространства памяти: там ее задача -
раздать максимум предупреждений тем, кто способен их слушать.
> Вот с размером сложнее, он зависит от технологии
> отката, используемой в приложении. Скажем, в плюсовом приложнии
> в минимальном варианте throw вообще не ест памяти (если бросать
> заранее созданный глобальный статический объект), либо требует
> минимума памяти (std::exception и наследники с запасом поместятся в
> 4K-страницу). В более сложных вариантах может потребоваться создание
> каких-то объектов (например, LoggerRecord()). Предсказать размер
> не представляется возможным, так что процесс должен сам сказать,
> сколько памяти ему нужно для отката. Как? Можно добавить константу в
Системный вызов добавить.
А размер - да хотя 10% текущей памяти плюс константа.
Перерасход на 10% - это не разы и в нынешней обстановке почти ничего
не стоит. В отличие от надежности.
> Лично я думаю, что подобный механизм гораздо лучше тупого OOMK,
> и операционка, его имеющая, выиграет в надежности.
> Comments?
/netch
Serge A. Suchkov
>>>>Serge A. Suchkov wrote:
>>>>
>
>>> Да понял я все про капабилитис, уже в TODO внес, только вот ...
>>> как мне различить system shutdown (пришел sigterm) и OOMK (пришел
>>> sigterm)? По каким-то внешним проявлениям? Криво.
>>>
>>При старте процесса отфоркай следилку ...
>>если в некий момент времени пятнашку получает и следилка и сам рабочий
>>процесс
>>то она раздавалась по -1 (всем) - это шутдаун
>>- если SIGTERM получает только рабочий процесс - это subjевый случай
>>
>
>IMO это просто не будет работать, потому что если системе плохо,
>
Ну не настолько уж и плохо :) я в контексте сей дискусии написал
маленький тестик - который
отрабатывал SIGTERM и при этом еще умудрялся юзать Mozillу и пару-тройку
xterm-ов (с mtop, procinfo etc.) + по мелочи ...
- при этом OOMk ни разу не промахнулся :)) правда машинка достаточно
толста (512ram+1Gbswap)
и ему трудно спутать крошечную мазиллу c RSZ=54M с околополуторагиговым
монстром :)
>
>то процессы получат управление с сильным разрывом по времени и
>сговориться, что это было и почему, они просто не успеют...
>
то что сигнал _весьма_ асинхронен - эт верно а вот будет работать такая
схема или не будет - сейчас потестим :)
>
>
>/netch
>
--
Serge.
Serge A. Suchkov
> Valentin Nechayev wrote:
>
>> IMO это просто не будет работать, потому что если системе плохо,
>
Тест показал что в лабораторных условиях это так или иначе но работает
как это будет на реальной софтине ХЗ
>>
>
--
Serge.
Ilya Anfimov
Valentin Nechayev <ne...@segfault.kiev.ua> wrote:
>>>> Vladimir Dozen wrote:
>
>>
[skipped]
>> Лично я поддерживаю идею Нечаева о некоем НЗ-пуле страниц для
>> каждого(?) процесса, и приходе сигнала, когда выделить страницу
>> неоткуда, кроме как из этого пула (2VN: я правильно понял?).
>
>Примерно. Ваша интерпретация даже лучше первоначальной идеи.
>
>> Вопрос в интерфейсе -- какие процессы должны иметь пул и каков
>> должен быть его размер. "Какие" -- это, видимо, довольно просто --
>> если приложение регистрирует обработчик SIGXMEM (вариант -- SIGBUS),
>> то ему нужен пул.
>
>Я бы сделал не так. Кому нужен такой пул - тот явно его закажет явным запросом.
>Вопли типа "нефиг лишние сисколлы разводить" идут, естественно, нафиг.
Да ведь действительно нефиг.
>Требуется: узнавание текущего размера; задание желаемого (может обвалиться);
>задание границы для генерации сигнала. Также узнавание (без плясок с бубном
>над procfs): сколько VM всего у процесса, сколько private, сколько shared
>(включая cow), сколько uncommitted. Также команду сделать заданное количество
>(и место) cow памяти личной.
Почему бы и не через procfs, без бубна.
>
>Кому все это не нужно - будет максимум шарить и дохнуть по сигналу при попытке
>коммита. Кому нужно - будет страховаться.
>
[skipped]
>
>> Лично я думаю, что подобный механизм гораздо лучше тупого OOMK,
>> и операционка, его имеющая, выиграет в надежности.
>> Comments?
Вообще, идея выглядит очень здравой. Спасение утопающих -- дело
рук самих утопающих.
Я пока что не понимаю, как может разруливаться та же самая
ситуация, в которой ошибаются и все виденные мной киллеры:
кто-то отожирает кучу памяти. И количесвто отожранной памяти
продолжает возрастать. На посланные всем желающим предупреждения
он плевал. Память быстро кончилась. После этого, конечно, велика
верятность, что прибьют именно его. Но может статься, что умрет
как раз самый нужный процесс, который честно среагировал на
предупреждение и как раз повернулся чтобы память поосвобождать.
Ну и наконец: я пока не видел даже реализации сравнительно
простой вещи -- чтобы под все cow резервировалась память, и
никаких OOMK в принципе не требовалось. Так что кто будет делать
вышесказанное -- совсем не ясно.
>
>
>/netch
Valentin Nechayev
> >Требуется: узнавание текущего размера; задание желаемого (может обвалиться);
> >задание границы для генерации сигнала. Также узнавание (без плясок с бубном
> >над procfs): сколько VM всего у процесса, сколько private, сколько shared
> >(включая cow), сколько uncommitted. Также команду сделать заданное количество
> >(и место) cow памяти личной.
> Почему бы и не через procfs, без бубна.
Где procfs в Posix или SUS?
Где гарантия, что оно будет именно в /proc и не выше topdir?
Оно конечно просто - спихнуть все в /proc и забыть.
А потом грабли огребать.
> Я пока что не понимаю, как может разруливаться та же самая
> ситуация, в которой ошибаются и все виденные мной киллеры:
>
> кто-то отожирает кучу памяти. И количесвто отожранной памяти
> продолжает возрастать. На посланные всем желающим предупреждения
> он плевал. Память быстро кончилась. После этого, конечно, велика
> верятность, что прибьют именно его. Но может статься, что умрет
> как раз самый нужный процесс, который честно среагировал на
> предупреждение и как раз повернулся чтобы память поосвобождать.
Вы, вероятно, ограниченно прочли этот тред.
Мягкий, аккуратный недопуск впадания в позу исчерпания всей памяти -
вместо того, чтобы плеваться SIGKILL'ами - одна тема.
Демпфирование таких ситуаций, от жестких вариантов типа невыдачи памяти
нерутовым процессам при занятии 90% VM - до мягких с нормальными,
а не кривыми rlimit'ами, квотами - вопрос корректности поведения
операционки.
Вопрос же, как с этим поступать в условиях, когда вместо явного запроса
памяти и явного облома оного запроса есть неявные запросы через
lazy commit, модификацию COW страниц и т.д. - второй вопрос.
Связь его с первым - фактически только та, что это средства для работы
в одном пространстве, одной подсистеме.
Я писал на тему второго вопроса. Первый - был обжеван со всех сторон
ранее.
> Ну и наконец: я пока не видел даже реализации сравнительно
> простой вещи -- чтобы под все cow резервировалась память, и
> никаких OOMK в принципе не требовалось. Так что кто будет делать
> вышесказанное -- совсем не ясно.
А мы тут пока что трындим, Вы разве не заметили? ;))
Кто будет реализовывать? А кто знает настолько хорошо VM,
чтобы влезть в нее немытыми руками и ничего не сломать?
Я такими талантами похвастаться не могу.
/netch
Vladimir Dozen
> > каждого(?) процесса, и приходе сигнала, когда выделить страницу
> > неоткуда, кроме как из этого пула (2VN: я правильно понял?).
>
> Примерно. Ваша интерпретация даже лучше первоначальной идеи.
А сигнал какой? Таки SIGXMEM?
> > Вопрос в интерфейсе -- какие процессы должны иметь пул и каков
> > должен быть его размер. "Какие" -- это, видимо, довольно просто --
> > если приложение регистрирует обработчик SIGXMEM (вариант -- SIGBUS),
> > то ему нужен пул.
> Я бы сделал не так. Кому нужен такой пул -
> тот явно его закажет явным запросом.
Да, по определенном размышлении я тоже решил, что явный заказ
правильнее, и, вероятно, прямее ( == проще ) в реализации.
> Требуется: узнавание текущего размера; задание желаемого (может обвалиться);
> задание границы для генерации сигнала. Также узнавание (без плясок с бубном
Мгм. А зачем два размера? Мне казалось, что граница генерации -- это
как раз размер пула?
> над procfs): сколько VM всего у процесса, сколько private, сколько shared
> (включая cow), сколько uncommitted. Также команду сделать заданное количество
> (и место) cow памяти личной.
А последний пункт зачем?
Ну, и главный вопрос повестки дня: как все это сделать? Достаточно
ли послать send-pr (я пока забил на линукс, я честно скажу кастомерам,
что приняты такие-то меры -- какие еще не решил -- но стопроцентного
выживания под OOM не гарантирую) в FreeBSD-team, или надо таки рожать
патч самим? То есть, интересует наиболее простая процедура получить
эту функциональность.
P.S. Пул, кстати, можно выполнить как mmap-файл где-то в /var/run.
--
dozen @ home
Vladimir Dozen
> А мы тут пока что трындим, Вы разве не заметили? ;))
> Кто будет реализовывать? А кто знает настолько хорошо VM,
> чтобы влезть в нее немытыми руками и ничего не сломать?
> Я такими талантами похвастаться не могу.
Ясная спецификации, тем не менее, существенно облегчает
любую работу. Так что "трындим" -- это вырабатываем
спецификацию. ;)
--
dozen @ home
yx
> Ну, и главный вопрос повестки дня: как все это сделать? Достаточно
> ли послать send-pr (я пока забил на линукс, я честно скажу кастомерам,
> что приняты такие-то меры -- какие еще не решил -- но стопроцентного
> выживания под OOM не гарантирую) в FreeBSD-team, или надо таки рожать
> патч самим? То есть, интересует наиболее простая процедура получить
> эту функциональность.
>
да ну! бредим все дальше? это не решение, если бы внимательней посмотрели
существующий код, то увидели бы что и ватерлинии(предлагали резерв?)
существуют(по кр.мере в линухе), и overcommit ситуацию исчерпания vm
не спасет. И что процесс пристреливается не сразу. И еще много чего
не упомянутого..
Дело в том что, если понятна идея - реализация дело времени и не важно кем,
здесь же решения не-вид-но, сорри imho.
Относительно добавления новых сисколов - это в лес, причем в далекий.
Вспомнили бы с каким трудом удалось впихнуть дополн. сисколы, связанные
с новыми fs в линухе. Для этого нужны веские обоснования. Здесь же, случай
только одной спец.задачи, непонятно кому нужной, и тем не менее предлагаете
плодить новые сисколы?
(почему не посмотреть и не подумать как реализован тот же mempool в squid?).
Относительно freebsd - так там и не oom killer - а какая-то тривиальная
пародия (даже не на линух). Опять сорри, но это так - и это факт.
> P.S. Пул, кстати, можно выполнить как mmap-файл где-то в /var/run.
>
ню-ню, можно все, если это идиоцеобразно..))
надоело, и прямо таки скучно.. просто bye.
--
Vladimir Yakovetsky
Vladimir Dozen
> да ну! бредим все дальше? это не решение, если бы внимательней посмотрели
> существующий код, то увидели бы что и ватерлинии(предлагали резерв?)
> существуют(по кр.мере в линухе), и overcommit ситуацию исчерпания vm
> не спасет. И что процесс пристреливается не сразу. И еще много чего
> не упомянутого..
Я, наверное, тебя не понимаю. Если все это (ватерлинии) есть, то
почему это не работает? Все, что мне здесь предлагалось для linux
(в том числе и тобой) -- это все полумеры, по-простому -- это НЕ
работает.
> Дело в том что, если понятна идея - реализация дело времени и не важно кем,
> здесь же решения не-вид-но, сорри imho.
Можешь предложить сценарий, при котором резерв страниц с посылкой
сигнала не даст приложению корректно откатится/завершиться?
Даже в самом (?) худшем случае -- жорка съедает всю раму, но
замирает как раз съев последнюю страницу, просыпается наша приблуда,
хочет страницу, ей шлют SIGXMEM, она _может_ сделать откат или
спокойно выйти, корректно закрыв все файлы, потому что у нее есть
резерв. Я уж не говорю про случай, когда жорка -- это мы, тогда
просто делается большой откат, и все -- памяти снова навалом.
Если приложение не обрабатывает сигнал, то (как и для всего
семейства SIGX*) дефолтовое действие -- убить. Внешне это ничем
не отличается от текущего убивания, то есть ситуация как минимум
не станет хуже.
> (почему не посмотреть и не подумать как реализован тот же mempool в squid?).
Слушай, как бы ни был -- ну не спасает ЛЮБАЯ техника выделения
памяти от тупого убивания. Тут систему менять надо.
> Относительно freebsd - так там и не oom killer - а какая-то тривиальная
> пародия (даже не на линух). Опять сорри, но это так - и это факт.
Это неважно. Порочен сам подход. "А у нас самая прямая из всех кривых
техник" -- это не повод гордиться.
--
dozen @ home
Valentin Nechayev
> > Ну, и главный вопрос повестки дня: как все это сделать? Достаточно
> > ли послать send-pr (я пока забил на линукс, я честно скажу кастомерам,
> > что приняты такие-то меры -- какие еще не решил -- но стопроцентного
> > выживания под OOM не гарантирую) в FreeBSD-team, или надо таки рожать
> > патч самим? То есть, интересует наиболее простая процедура получить
> > эту функциональность.
> >
> да ну! бредим все дальше? это не решение, если бы внимательней посмотрели
> существующий код, то увидели бы что и ватерлинии(предлагали резерв?)
> существуют(по кр.мере в линухе), и overcommit ситуацию исчерпания vm
Ась? Ткни пальцем. Где они, какие. Как ими управлять. Что могут.
> не спасет. И что процесс пристреливается не сразу. И еще много чего
> не упомянутого..
Список в студию!
> Относительно добавления новых сисколов - это в лес, причем в далекий.
> Вспомнили бы с каким трудом удалось впихнуть дополн. сисколы, связанные
> с новыми fs в линухе. Для этого нужны веские обоснования. Здесь же, случай
> только одной спец.задачи, непонятно кому нужной, и тем не менее предлагаете
Да-да. Я согласен с тем, что для gnome эти функции не нужны - он все равно
их не будет использовать.
> плодить новые сисколы?
> (почему не посмотреть и не подумать как реализован тот же mempool в squid?).
Расскажи. То, что ты там увидел. Сравним видение.
> надоело, и прямо таки скучно.. просто bye.
Ну так не участвуй. А то пришел, поманил условно существующими соблазнами,
до которых мы, сирые, не можем докопаться, и снова спрятался.
Твое право, но если рассказа не будет - считаю, что это все были мифы
и миражи. ;)
/netch
Vladimir Silyaev
>> >> malloc+commit
>> >> некоего большого кусока памяти и собственно работа с этим куском через
>> >> свой собственный механизм работы с пулом
>> >
>> > Вот и убъют тебя на коммите. Так здесь принято. :(
>> Ты не понял, коммит делается непосредственно после запуска програмы,
>> а в процессе работы программа от системы ничего больше не просит.
>
> Во-первых, откуда мне знать, сколько захочет следующий клиент,
не можещь, посылаешь клиента курить. А твой клиент пусть раскручивается
на больше памяти.
> во-вторых, какоя для системы разница, прошу я 2G сразу после старта
> или через сутки? Все равно столько нету, и все равно на доступе получу
> убиение.
При старте делаешь malloc на XXMByte (или 0.75 RAM если XX больше)
и после этого memset на нее родимую, если ты живой после memset, все
память твоя.
Конечно такая схема не спасет от отьедания памяти другими задачами,
и твоей программе быть невинно обуиенной, как самой толстой.
--
Владимир
Vladimir Silyaev
> VNS> А, на $@#$, если это все равно никто использовать не будет.
>
>Если ввести тайком - то да.
>Если сделать нормально - разные гномы, которые ничего кроме как схлопнуться
>не умеют, пусть себе хлопаются. Нормальный софт, рассчитанный на то,
>чтобы сделать свое дело и выжить в ограниченных ресурсах - будет использовать,
их героически преодолевать.
Если же нужно жить в действительно ограниченных ресурсах, то эти ресурсы
и нужно выделить их во время запуска, а потом от системы ничего больше
не просить. Конечно это не спасет от "диких" програм, но от них
не спасет и обсуждаемая тут супер навороченная стратегия, ни precommit.
А что реально может спасти в таких ситуациях - это лимиты не для
процесса, а скажем на уровне пользователя (uid), с "бюджетом"
для процессов не попадающих под никакие другие лимиты. Вот тогда,
после правильного разделения, и malloc сразу NULL начнет возвращать,
и overcommit не нужен (лимиты можно считать не по памяти, а
по адресному пространству).
> VNS> А обсуждаемая проблема imho, не стоит и въеденного яйца, все что
> VNS> нужно делать если в системе кончилось место в своп'е - это:
> VNS> - проверить, на наличие диких процессов отъевших память, если
> VNS> таковый есть, то поставить limits на память и
> VNS> кол-во процессов для этого uid
> VNS> - если все процессы правильные, добавить свопа.
>
>Ага, ага. Задним числом, когда уже пристрелили то, что должно жить?
>А если sshd пристрелят?
Ну если под кончилось подразумевать, осталось меньше XXMByte, то
никого и не пристрелят.
> VNS> Вторую часть можно и автоматизировать, если есть такое желание.
>
>Угу. И повторяя до бесконечности. И 20*RAM выжрут, и 100*RAM.
>Медленнее, но выжрут. Прожорливость - она штука постоянная.
Если они выжрут по хорошему, то значит не жить им на этом железе,
поскольку последние 99*RAM они будут выжирать очень долго.
А если программа просто теряет память (или аллоцирует, все что
аллоцируется) по система тут уже ничем не поможет.
> VNS> P.S. В простейшем случае в своей программе можно периодически проверять
> VNS> размер свободного места в свопе, и если оно стремится к нулю, плавно
> VNS> умерить аппетиты в памяти, и/или спокойно склеить ласты.
>Race condition в чистом виде, однако.
Ну почему же, если видно что свопа меньше XX мбайт, и лояльные программы
не съедают больше чем Y в секунду, то особых гонок нет.
И конечно иметь в limits осмысленный datasize меньше чем объем
памяти может тоже помочь.
--
Владимир
Vladimir Silyaev
>> А SIGKILL раздается не тогда, когда не хватает физической памяти,
>> а когда кончается виртуальная память (RAW+swap). В случае же
>> когда куча(heap) находится на mmap'ленном файле размер виртуальной
>> памяти доступной системе увеличивается на размер такой кучи.
>
>Случай применения mmap("/dev/zero") как механизм выделения памяти Вам
>совершенно незнаком? В этом случае занимается своп, а не диск.
делать MAP_ANON, если в качестве "подложки" хочется истользовать своп.
А mmap на _файл_ делается для того, чтобы не занимать системную виртуальную
память, на которой, контроля нет (если такой контроль есть, то весь
этот тред особого смысла не имеет).
>> Ты не понял, коммит делается непосредственно после запуска програмы,
>> а в процессе работы программа от системы ничего больше не просит.
>
>У программы все равно есть собственная незамапленная на файл память.
>Значит, ее могут за это убить.
Программу можно написать так, что этой памяти будет не больше, чем скажем
у syslog'а. А код и неизменяемые данные, и так замаплен на файл и свопа
не просит, хотя вот за стек'ом надо следить.
--
Владимир