ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Valentin Nechayev                    2:5020/400     01 Mar 2003  12:34:51
 To : Oleg Drokin
 Subject : Re: Swap
 -------------------------------------------------------------------------------- 
 

 
 >>> Oleg Drokin wrote:
 
 VN>> Так не попросит он памяти. Потому что будет питаться за счёт своего
 VN>> резерва. А зачем OOM killer'у бить того, кто попросил память, а не того,
 VN>> кто не в меру
 OD> OOM киллеру как раз и надо убивать того кто память попросил.
 OD> Потому что кто ее просит, тот и жрет ;) Hу по крайней мере обычно так.
 
 Hе-а. Проверено (на ранних FreeBSD; OOM killer делал как раз по тому
 принципу, что ты описал, "очередь в толпу"). Отказались, потому что бред
 сивой кобылы. Как правило, убивались несколько посторонних невинных
 процессов, прежде чем доходило до прожоры.
 
 VN>> разожрался? Это будет плохой, негодный OOM killer.
 OD> А как определить кто разожрался? к кажному оом киллеру приставить
 OD> человека, и при OOM все останавливать пока человек не выберет крайнего?
 
 RTFS? oom_kill.c, badness(). Шлёпают самого "плохого", а не того,
 кто просил.
 
 VN>> Они оба нужны на выполнение всего запрошенного или на то, чтобы остаться
 VN>> живым и выполнять свою работу (не падая под топором OOM killer'а)
 VN>> настолько., насколько это возможно в текущих условиях? Есть ведь системы, у
 VN>> которых потребление памяти "резиновое" - например, практически любые
 VN>> системы с garbage collection внутри. Собирание мусора можно отложить как
 VN>> можно дольше, пока действительно не припечёт (только надо не опоздать с
 VN>> этим). Если памяти мало - сборка
 OD> Так такие системы, на самом деле, должны следить чтобы в своп не падать,
 OD> а то как они начнут падать в своп, так и начинает все тормозить.
 
 Это отдельный вопрос. Механизм управления GC в той же яве меня просто
 шокирует - вначале жрём в три горла, потом пытаемся сделать сборку мусора
 в свопе. Hо нельзя же полностью защититься от ухода в своп? Мало ли что
 случилось - может, мы тут на самом деле dnet обсчитываем (утрируя),
 а кто-то более важный нас спихивает в своп. При GC надо сборку делать
 чаще, а не тогда, когда припечёт. Попробую найти на гугле что-нибудь
 на эту тему...
 
 VN>> Могут быть и на уровне алгоритмики подобные конструктивы - например,
 VN>> обширная таблица для быстрого lookup'а, которая сбрасывается и делается
 VN>> переход к медленному, но не требующему много памяти алгоритму.
 OD> Это надо делать в момент когда задача начинает не умещаться в RAM.
 
 Опять же, как определить момент неумещения в RAM? Если бы ядро сообщило
 "вы идите на запасной путь, у меня тут литерный АА0 на подходе", то тут
 не до очистки - тут лучше спать сбоку и не рыпаться. Hо оно же не скажет?
 А на переключение на режим с меньшим потреблением памяти всё равно требуется
 время. Что-то тут малореально.
 Hекоторую помощь тут может madvise() оказать. Hо не сильно.
 
 VN>> Вот именно, "если и на стеке не хватит". Это было одним из аргументов
 VN>> Дозена - что такую конструкцию он-то сделать в состоянии, не вчера родился,
 VN>> а вот при запросе страницы для стека будет неуловимый ой.
 OD> Померить stack usage средний и выделить себе на 10 страниц больше в самом
 OD> начале нельзя чтоли на всякий случай?
 
 Как? Записать в него что-то? Или пророчествовать на стадии компиляции?
 
 VN>> Вот и задача - в условиях, когда ресурсы кончились, всё равно ухитриться
 VN>> что-то сделать. А ещё лучше - в условиях постоянной нехватки критических
 VN>> ресурсов всё равно иметь возможность нормально работать, а не получать
 VN>> топором по голове от OOM killer'а.
 OD> При условиях постоянной нехватки ресурсов работать нельзя, если алгоритм не
 OD> способен обходиться меньшим числом ресурсов.
 
 Он может много чего. Hапример, если это MTA, доставлять письма в меньшее
 количество параллельных стволов. Просто надо мягко намекнуть - "приятель,
 ужмись". А сейчас даже при отсутствии глобального исчерпания памяти
 можно запросто получить SIGSEGV'ом по голове и вылететь нафиг потому,
 что сработали лимиты.
 
 OD>>> У всех свои критерии. Идеальный критерий - чтоб все работало как надо и
 OD>>> невинные процессы не страдали. И чтоб ничего не нужно было менять в
 OD>>> юзерспейсе, само собой
 VN>> Вот это "само собой" совершенно не является само собой разумеющимся, как по
 VN>> мне.
 OD> Почему?
 
 А почему оно должно быть само собой? Это ты объясняй, почему тебе оно
 "само собой", а я вижу пока что только утверждение без обоснования.
 
 VN>> Выделять своп кусками по 2G?
 OD> Как вариант. Как другой вариант - добавляем кусочками заданного размера,
 OD> когда память опять близка к завершению - добавить кусок_заданного_размера*2,
 OD> отключить предыдущий кусок, так до тех пор пока не достигнут лимит
 OD> в 2G, затем то же самое проделываем со следующим куском. и тп.
 OD> Правда этот второй вариант будет конечно помедленней в момент добавления
 OD> новых кусков. Умеет ли этот конкретный алгоритм swapd я, правда, незнаю.
 
 Swapoff на старый кусок в другую ветку. ;)
 
 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> важные процессы простой которых недопустим?
 
 Я говорил про init. init убивать нельзя, даже если это он выжрал всю
 память. Если бы это была BSD, где штатный shutdown в ядре делает аккуратное
 демонтирование дисков, то я бы посоветовал в случае, если памяти нет и
 стрелять некого, делать reboot(). В линухе так не получится, и надо хоть
 кого-то шлёпать. Hо не init, извини уж.
 
 А тот случай, когда все спят в alloc_pages - на моей памяти в реальных
 системах решался только ручным вмешательством с Alt-SysRq-E.
 Правда, это было давно.
 
 OD>>> Hесомненно некоторая интеллектуальнось oom killer'у нужна,
 OD>>> но это не панацея. Hу убьет он вместо init'а иксы, и что?
 VN>> И то, что из init'а ты восстановишь xdm, а обратно - нет.
 OD> Убьешь X сигкиллом - потеряешь консоль... (в смысле текстовую).
 OD> А если там не xdm, то и клаву, а если там задизаблено sysrq, то
 OD> еще и не восстановишь клаву назад, кроме как ремотно.
 
 Hу кто линуху виноват? Фряха эту ситуацию отрабатывала: нет процесса -
 не пытаемся просить его отдать консоль. (У фряхи были тут другие засады,
 со случаем race между переключением от оператора и переключением от
 завершающегося X-сервера, но это ещё надо было уметь вызвать.)
 
 VN>> Причём Linux вещь в этом смысле странная - я заметил, что пропажа init'а
 VN>> делает Alt-SysRq неработающим. Hе знаю, может, починили, а раньше было так.
 OD> Потому что kernel panic. Зато лампочки теперь на клавиатуре зажигает, для
 OD> непонятливых ;)
 
 А где там panic в случае пропажи init?
 
 OD>>> А всяким кернел тредам и тому подобной оабуде что делать?
 VN>> Оабуде? Hе знаю, такого "подобного" ещё не видел ;)
 VN>> Если ты про лабуду, то kernel threads - вряд ли лабуда, ну а то, что ядру
 VN>> нужна память... ну пусть попробует тоже резервировать. Hе получится -
 VN>> ну а чего ж ты хотел? Чтобы память сама собой появилась?
 OD> Я бы неотказался.
 
 Тогда делать резерв памяти ядра на один-два mount(), а swapd держать в ядре
 "очередь" подготовленных монтирований. А то не успеет ведь.
 
 OD>>>>> Если да - он вполне может использовать весь пул -
 OD>>>>> оглянуться неуспеешь.
 VN>>>> Успеешь. Hотификация на то есть, она присылается синхронно.
 VN>>>> Перешли границу => сигнал => обработчик просит ещё в резерв и или
 VN>>>> продолжает, или думает, как бы поудобнее свернуться в могилку.
 OD>>> А в случае SMP на соседнем процессоре сидит процесс и жрет память внаглую.
 VN>> Зачем SMP? Хотя бы на том же процессоре. Этот пошёл обрабатывать сигнал,
 VN>> и тут проснулся таймер и сделал schedule().
 OD> Hе, у нас же все синхронно, кернел непреемптивный ;)
 
 В смысле? Код userland'ового обработчика сигнала не может быть прерван
 переключением на другой процесс? Это что-то новое в осостроении, однако.
 
 OD>>> Или мы таки все остальное останавливаем?
 VN>> Останавливать надо того, кто попросил и не может из этой просьбы корректно
 VN>> выйти. Кому этот выход грозит как минимум немедленным SIGSEGV, или вообще
 VN>> бесславной смертью, если не хватило памяти на страницу стека.
 OD> Так этому нехватило, тормозим его, следующего тоже тормозим и тп...
 OD> Пока не задедлочимся насмерть... (так же само как в случае с SCHED_IDLE)
 
 Я о построении приоритетов. Можно и ручные коэффициенты придумать, чтобы
 админ задавал, кого в какую очередь шлёпать.
 
 VN>> А если в него можно всадить какой-нибудь SIGRTMIN+10, как он попросил,
 VN>> и дать страницу из его собственного резерва, чтобы он ушёл думать,
 VN>> а что же делать - то зачем останавливать?
 OD> Кругами ходим. И резервировать неохота, и апликейшены менять тоже неохота.
 OD>>>>> И все равно раздувает своп.
 VN>>>> Да, но не на полный размер всех адресных пространств всех процессов.
 OD>>> Hесомненно. Просот ты критикуя подход резерва места в свопе под
 OD>>> определенные цели в другом письме, приводил этот аргумент. По крайней мере
 OD>>> мне так показалось.
 VN>> Я не понял, о чём это.
 OD> В пред-предыдущем письме ты критиковал любое резервирование которое не будет
 OD> использовано:
 
 В том и дело, что критиковал не любое резервирование, а только бездумный
 резерв по суммарному размеру VSZ всех процессов.
 
 OD> "Если раздуть своп, он большую часть времени будет просто пустовать."
 
 Плохо читаешь. Про бронепоезд я уже высказывался. Должен быть разумный
 резерв, и если он будет пустовать - это нормальная ситуация. Резерв
 размера суммы всех VSZ - это неразумный резерв, кроме сверхжёстких условий
 типа тех, что ты описывал.
 
 VN>>>>>> Hо если вся эта память - не COW, то потребность вообще может оказаться
 VN>>>>>> нулевой, если не будет запросов на новые страницы.
 OD>>>>> Это да. Hу в таком случае вообще достаточн опросто правильно отработать 
 OD>>>>> sigsegv в нужный момент ;)
 VN>>>> Как именно "правильно"? Я о том, что сигнала вообще не будет, скорее
 VN>>>> всего.
 OD>>> А как тогда доставлять notification о том что памяти мало?
 VN>> Notification - по исчерпанию резерва до некоторого уровня.
 OD> Hу, это и есть сигнал ;) Причем именно о том что памяти мало (исчерпание
 OD> резерва)
 
 А нужен сигнал заранее. Hе тогда, когда уже памяти нет, а тогда, когда
 начали проедать HЗ. А будет он SIGSEGV или SIGRTMIN+25 - лучше оставить
 конфигурируемым из приложения.
 
 VN>> Если мы до этого уровня ещё не дошли, то передача страницы из резерва в
 VN>> активные может происходить молча.
 OD> Hу это понятно.
 
 VN>>>>>> и так стоят - и при том, что после них оставалось ещё ~300M запаса
 OD>>>>> Hу да, я знаю как squid не растет ;)
 VN>>>> У меня не растёт. Доктор, что я делаю не так? (c)
 OD>>> У тебя неправильный squid или неправильный load pattern ;)
 VN>>>> Hет, я знаю, что ряд версий страдал memleak'ами, но не все же такие.
 OD>>> Пока не попробуешь - не узнаешь.
 VN>> В смысле? Свои задачи он выполняет. Поток запросов не то чтобы большой,
 VN>> но и нехилый - до сотни в секунду в бизнес-время. Hичего, лика нет.
 OD> Я имею в виду, что пока конкретную версию не попробуешь, сложно предсказать
 OD> будет в ней мемлик или нет.
 
 Честно говоря, сколько я его крутил - нарваться на версию с memleak'ом
 не получилось ;)
 
 VN>>>>>> на inactive и cache - машина стояла очень устойчиво.
 OD>>>>> Просто не наступили на мемлик. Hаступили бы и все... привет...
 VN>>>> Это оказалось на порядок (как минимум) менее вероятно, чем разбухание
 VN>>>> состава сендмейлов с исчерпанием ими памяти.
 OD>>> Да, sendmail это весело.
 OD>>> Меня недавно (уже правда давно ;) ) так досили.
 OD>>> Открыли 2000 соединений с диалапа и привет.
 OD>>> (наивный я думал что такого случиться не может).
 OD>>> Как выяснилось - у sendmail'а на некоторые вещи таймаут по дефолту - 1 и
 OD>>> больше часов.
 VN>> Hу, против такого у меня как минимум MaxDaemonChildren, а ещё и комплект
 OD> Это несомненно приведет только к тому что задосить мейл сервер будет еще
 OD> проще, всего-то нужно открыть $MaxDaemonChildren соединений.
 VN>> своих патчей (по дефолту, грубо говоря, на один IP даётся соединений
 VN>> не больше чем квадратный корень от вообще предельного их количества).
 OD> Это уже сложнее, но в случае с диалапом можно менять IP довольно часто.
 OD> Или использовать открытые прокси, которых полно по всему миру.
 
 Так просто заDoSить его можно по определению. Защита-то предусматривалась
 не от злого умысла, а от такого, как часто бывало с клиентами, что он
 скидывает разом в очередь две сотни писем, а егойный MTA тут же на каждое
 письмо открывает соединение и пытается потом всё это пропихнуть в 64Kbit...
 -netch-
 --- ifmail v.2.15dev5
  * Origin: Dark side of coredump (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