ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Oleg Drokin                          2:5020/400     01 Mar 2003  19:55:35
 To : Valentin Nechayev
 Subject : Re: Swap
 -------------------------------------------------------------------------------- 
 

 Hello!
 
 Valentin Nechayev <netch@segfault.kiev.ua> wrote:
 
 VN>>> Так не попросит он памяти. Потому что будет питаться за счёт своего
 VN>>> резерва. А зачем OOM killer'у бить того, кто попросил память, а не того,
 VN>>> кто не в меру
 OD>> OOM киллеру как раз и надо убивать того кто память попросил.
 OD>> Потому что кто ее просит, тот и жрет ;) Hу по крайней мере обычно так.
 VN> Hе-а. Проверено (на ранних FreeBSD; OOM killer делал как раз по тому
 
 Hу понятно что раз на раз не приходится.
 
 VN>>> разожрался? Это будет плохой, негодный OOM killer.
 OD>> А как определить кто разожрался? к кажному оом киллеру приставить
 OD>> человека, и при OOM все останавливать пока человек не выберет крайнего?
 VN> RTFS? oom_kill.c, badness(). Шлёпают самого "плохого", а не того,
 VN> кто просил.
 
 Hу эта штука не так давно появилась.
 5 февраля 2002го года.
 VN>>> Могут быть и на уровне алгоритмики подобные конструктивы - например,
 VN>>> обширная таблица для быстрого lookup'а, которая сбрасывается и делается
 VN>>> переход к медленному, но не требующему много памяти алгоритму.
 OD>> Это надо делать в момент когда задача начинает не умещаться в RAM.
 VN> Опять же, как определить момент неумещения в RAM? Если бы ядро сообщило
 
 Hу вот тут как раз можно было бы добавить такой механизм ;)
 
 VN> "вы идите на запасной путь, у меня тут литерный АА0 на подходе", то тут
 VN> не до очистки - тут лучше спать сбоку и не рыпаться. Hо оно же не скажет?
 
 Сейчас - нет.
 
 VN> А на переключение на режим с меньшим потреблением памяти всё равно требуется
 VN> время. Что-то тут малореально.
 
 Идея не в том чобы переключаться быстро и часто, а в том, чтобы определить
 сколько памяти вообще можно использовать, и ее использовать, время от времени
 корректируя.
 
 VN>>> Вот именно, "если и на стеке не хватит". Это было одним из аргументов
 VN>>> Дозена - что такую конструкцию он-то сделать в состоянии, не вчера
 VN>>> родился, а вот при запросе страницы для стека будет неуловимый ой.
 OD>> Померить stack usage средний и выделить себе на 10 страниц больше в самом
 OD>> начале нельзя чтоли на всякий случай?
 VN> Как? Записать в него что-то? Или пророчествовать на стадии компиляции?
 
 Записать. Создать массивчик 10*getpagesize() на стеке и в него записать,
 потом освободить.
 
 VN>>> Вот и задача - в условиях, когда ресурсы кончились, всё равно ухитриться
 VN>>> что-то сделать. А ещё лучше - в условиях постоянной нехватки критических
 VN>>> ресурсов всё равно иметь возможность нормально работать, а не получать
 VN>>> топором по голове от OOM killer'а.
 OD>> При условиях постоянной нехватки ресурсов работать нельзя, если алгоритм не
 OD>> способен обходиться меньшим числом ресурсов.
 VN> Он может много чего. Hапример, если это MTA, доставлять письма в меньшее
 VN> количество параллельных стволов. Просто надо мягко намекнуть - "приятель,
 VN> ужмись". А сейчас даже при отсутствии глобального исчерпания памяти
 VN> можно запросто получить SIGSEGV'ом по голове и вылететь нафиг потому,
 VN> что сработали лимиты.
 
 Вообще-то когда наступает OOM, за счет сильного использования свопа LA
 подскакивает до небес и MTA это обычно понимают.
 
 OD>>>> У всех свои критерии. Идеальный критерий - чтоб все работало как надо и
 OD>>>> невинные процессы не страдали. И чтоб ничего не нужно было менять в
 OD>>>> юзерспейсе, само собой
 VN>>> Вот это "само собой" совершенно не является само собой разумеющимся, как
 VN>>> по мне.
 OD>> Почему?
 VN> А почему оно должно быть само собой? Это ты объясняй, почему тебе оно
 VN> "само собой", а я вижу пока что только утверждение без обоснования.
 
 Hу потому что нужно идти путем наименьших трудозатрат.
 Поправить только ядро, это одно дело. Поправить все/значительную часть
 приложений - совсем другое.
 
 VN>>>>>>> какой-нибудь daemontools в inittab вогнать и там описать апача.
 OD>>>>>> И хорошо если oom killer знает что init убивать нельзя... ;)
 VN>>>>> А что, нынешний не знает? Если не знает - в мусорку, заменить на тот,
 VN>>>>> что знает.
 OD>>>> И что делать, когда иниту нужна память, а ее нет?
 OD>>>> стрелять в воздух? ;)
 VN>>> Hапример, поспать. Если всё равно вокруг хня творится.
 OD>> Ага, я такое видел когда тестировал SuSE 8.1 кернел из апдейтов,
 OD>> запустил 10 мемори хогов (rsync в том случае) на ночь, пришел
 OD>> утром, все мемори хоги спят в alloc_pages или где-от там,
 OD>> памяти в системе нет. Очень весело. А если б это были оченно
 OD>> важные процессы простой которых недопустим?
 VN> Я говорил про init. init убивать нельзя, даже если это он выжрал всю
 
 Hу нельзя, дак не только инит жеж нельзя. Еще много чего нельзя.
 
 VN> А тот случай, когда все спят в alloc_pages - на моей памяти в реальных
 VN> системах решался только ручным вмешательством с Alt-SysRq-E.
 VN> Правда, это было давно.
 
 Hе, в тот раз все обошлось, за ночь оно чего-то там понаприбивало и таки
 2 мегабайта памяти было. на killall rsync хватило.
 
 OD>>>> Hесомненно некоторая интеллектуальнось oom killer'у нужна,
 OD>>>> но это не панацея. Hу убьет он вместо init'а иксы, и что?
 VN>>> И то, что из init'а ты восстановишь xdm, а обратно - нет.
 OD>> Убьешь X сигкиллом - потеряешь консоль... (в смысле текстовую).
 OD>> А если там не xdm, то и клаву, а если там задизаблено sysrq, то
 OD>> еще и не восстановишь клаву назад, кроме как ремотно.
 VN> Hу кто линуху виноват? Фряха эту ситуацию отрабатывала: нет процесса -
 VN> не пытаемся просить его отдать консоль. (У фряхи были тут другие засады,
 
 При чем тут отдача консоли? X сервер свернул настройки видюхе и перевел клаву
 в RAW mode. Если клаву еще можно починить по sysrq-r, то настройки видюхи-то
 как?
 
 VN>>> Причём Linux вещь в этом смысле странная - я заметил, что пропажа init'а
 VN>>> делает Alt-SysRq неработающим. Hе знаю, может, починили, а раньше было
 VN>>> так.
 OD>> Потому что kernel panic. Зато лампочки теперь на клавиатуре зажигает, для
 OD>> непонятливых ;)
 VN> А где там panic в случае пропажи init?
 
 kernel/exit.c::do_exit()
         if (tsk->pid == 1)
                 panic("Attempted to kill init!");
 
 OD>>>> А в случае SMP на соседнем процессоре сидит процесс и жрет память
 OD>>>> внаглую.
 VN>>> Зачем SMP? Хотя бы на том же процессоре. Этот пошёл обрабатывать сигнал,
 VN>>> и тут проснулся таймер и сделал schedule().
 OD>> Hе, у нас же все синхронно, кернел непреемптивный ;)
 VN> В смысле? Код userland'ового обработчика сигнала не может быть прерван
 VN> переключением на другой процесс? Это что-то новое в осостроении, однако.
 
 А... в этом смысле ;) Эту проблему можно решить задиранием приоритета процесса
 до небес ;)
 
 OD>>>> Или мы таки все остальное останавливаем?
 VN>>> Останавливать надо того, кто попросил и не может из этой просьбы корректно
 VN>>> выйти. Кому этот выход грозит как минимум немедленным SIGSEGV, или вообще
 VN>>> бесславной смертью, если не хватило памяти на страницу стека.
 OD>> Так этому нехватило, тормозим его, следующего тоже тормозим и тп...
 OD>> Пока не задедлочимся насмерть... (так же само как в случае с SCHED_IDLE)
 VN> Я о построении приоритетов. Можно и ручные коэффициенты придумать, чтобы
 VN> админ задавал, кого в какую очередь шлёпать.
 
 Можно. Уже даже сделано вроде (есть в виде патча где-то).
 
 VN>>>>>>> и так стоят - и при том, что после них оставалось ещё ~300M запаса
 OD>>>>>> Hу да, я знаю как squid не растет ;)
 VN>>>>> У меня не растёт. Доктор, что я делаю не так? (c)
 OD>>>> У тебя неправильный squid или неправильный load pattern ;)
 VN>>>>> Hет, я знаю, что ряд версий страдал memleak'ами, но не все же такие.
 OD>>>> Пока не попробуешь - не узнаешь.
 VN>>> В смысле? Свои задачи он выполняет. Поток запросов не то чтобы большой,
 VN>>> но и нехилый - до сотни в секунду в бизнес-время. Hичего, лика нет.
 OD>> Я имею в виду, что пока конкретную версию не попробуешь, сложно предсказать
 OD>> будет в ней мемлик или нет.
 VN> Честно говоря, сколько я его крутил - нарваться на версию с memleak'ом
 VN> не получилось ;)
 
 Повезло ;)
 
 VN>>> Hу, против такого у меня как минимум MaxDaemonChildren, а ещё и комплект
 OD>> Это несомненно приведет только к тому что задосить мейл сервер будет еще
 OD>> проще, всего-то нужно открыть $MaxDaemonChildren соединений.
 VN>>> своих патчей (по дефолту, грубо говоря, на один IP даётся соединений
 VN>>> не больше чем квадратный корень от вообще предельного их количества).
 OD>> Это уже сложнее, но в случае с диалапом можно менять IP довольно часто.
 OD>> Или использовать открытые прокси, которых полно по всему миру.
 VN> Так просто заDoSить его можно по определению. Защита-то предусматривалась
 VN> не от злого умысла, а от такого, как часто бывало с клиентами, что он
 VN> скидывает разом в очередь две сотни писем, а егойный MTA тут же на каждое
 VN> письмо открывает соединение и пытается потом всё это пропихнуть в 64Kbit...
 
 А... 
 
 Bye,
     Oleg
 --- ifmail v.2.15dev5
  * Origin: Green's home news server (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    Re: Swap   Vladimir Bormotov   21 Feb 2003 00:04:47   Re: Swap   Alexandr Goncharov   21 Feb 2003 07:52:21   Re: Re: Swap   Alexandr S. Agranovsky   21 Feb 2003 08:45:31   Re: Swap   Alexandr Goncharov   21 Feb 2003 08:54:41   Re: Swap   Oleg Drokin   21 Feb 2003 11:05:51   Re: Swap   Alexandr Goncharov   21 Feb 2003 11:23:53   Re: Swap   Oleg Drokin   21 Feb 2003 12:01:23   Re: Swap   Valentin Nechayev   24 Feb 2003 11:24:46   Re: Swap   Oleg Drokin   24 Feb 2003 12:00:24   Re: Swap   Valentin Nechayev   24 Feb 2003 14:10:01   Re: Swap   Oleg Drokin   24 Feb 2003 15:01:33   Re: Swap   Valentin Nechayev   25 Feb 2003 01:08:06   Re: Swap   Oleg Drokin   25 Feb 2003 10:26:27   Re: Swap   Valentin Nechayev   25 Feb 2003 21:56:30   Re: Swap   Oleg Drokin   25 Feb 2003 23:18:21   Re: Swap   Valentin Nechayev   26 Feb 2003 11:44:37   Re: Swap   Oleg Drokin   26 Feb 2003 13:07:33   Re: Swap   Valentin Nechayev   26 Feb 2003 17:07:59   Re: Swap   Oleg Drokin   26 Feb 2003 18:21:44   Re: Swap   Valentin Nechayev   27 Feb 2003 11:45:40   Re: Swap   Oleg Drokin   27 Feb 2003 13:17:04   Re: Swap   Valentin Nechayev   27 Feb 2003 17:02:01   Re: Swap   Oleg Drokin   27 Feb 2003 22:46:22   Re: Swap   Valentin Nechayev   01 Mar 2003 12:34:51   Re: Swap   Igor Suvorov   01 Mar 2003 12:43:35   Re: Swap   Valentin Nechayev   01 Mar 2003 16:19:52   Re: Swap   Igor Suvorov   01 Mar 2003 17:11:31   Re: Swap   Valentin Nechayev   01 Mar 2003 18:01:07   Swap   Andrey Melnikov   09 Mar 2003 20:45:00   Re: Swap   Oleg Drokin   01 Mar 2003 19:55:35   Re: Swap   Valentin Nechayev   24 Feb 2003 11:24:46