ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Oleg Drokin                          2:5020/400     27 Feb 2003  22:46:22
 To : Valentin Nechayev
 Subject : Re: Swap
 -------------------------------------------------------------------------------- 
 

 Hello!
 
 Valentin Nechayev <netch@segfault.kiev.ua> wrote:
 
 VN>>> А задача не в том, чтобы дать этому процессу кусок, а в том, чтобы
 VN>>> освободить память для всех.
 OD>> Правильно. Hо если освобождать путем убивания того кто попросил памяти в
 OD>> неправильный момент, то просто sigkill ему и никаких сложностей. ;)
 VN> Так не попросит он памяти. Потому что будет питаться за счёт своего резерва.
 VN> А зачем OOM killer'у бить того, кто попросил память, а не того, кто не в
 VN> меру
 
 OOM киллеру как раз и надо убивать того кто память попросил.
 Потому что кто ее просит, тот и жрет ;) Hу по крайней мере обычно так.
 
 VN> разожрался? Это будет плохой, негодный OOM killer.
 
 А как определить кто разожрался? к кажному оом киллеру приставить
 человека, и при OOM все останавливать пока человек не выберет крайнего?
 
 OD>> А если мы хотим чтоб он мог нормально завершиться - то уже приходится идти 
 OD>> на всякие ухищрения, при этом мы не уверены что умеет вообще нормально
 OD>> завершаться.
 VN> Вот пусть расскажет, умеет он нормально завершаться или нет.
 VN> Хочет резерва - значит, претендует на то, что умеет.
 
 Hу это да.
 
 VN>>> Это слишком жестоко для большинства случаев. Если, например, есть 100
 VN>>> единиц некоего ресурса, каждый из двух сервисов обычно кушает 10, но может
 VN>>> разожраться до 70 - нам что, увеличивать наличие ресурса до 140?
 OD>> Если мы знаем что одновременно они не разрастаются - то нет.
 OD>> Если знаем что могут разрастись и знаем что оба они нам нужны - то да.
 OD>> Если знаем что могут разрастись вместе, но не очень нужны - то нет. ;)
 VN> Они оба нужны на выполнение всего запрошенного или на то, чтобы остаться
 VN> живым и выполнять свою работу (не падая под топором OOM killer'а)
 VN> настолько., насколько это возможно в текущих условиях? Есть ведь системы, у 
 VN> которых потребление памяти "резиновое" - например, практически любые системы
 VN> с garbage collection внутри. Собирание мусора можно отложить как можно
 VN> дольше, пока действительно не припечёт (только надо не опоздать с этим).
 VN> Если памяти мало - сборка
 
 Так такие системы, на самом деле, должны следить чтобы в своп не падать,
 а то как они начнут падать в своп, так и начинает все тормозить.
 
 VN> Могут быть и на уровне алгоритмики подобные конструктивы - например,
 VN> обширная таблица для быстрого lookup'а, которая сбрасывается и делается
 VN> переход к медленному, но не требующему много памяти алгоритму.
 
 Это надо делать в момент когда задача начинает не умещаться в RAM.
 
 VN>>> Или же оставить 100 и дать возможность им разобраться, на сколько они
 VN>>> могут расти? (Это относится и к памяти, и к пропускной полосе на frame
 VN>>> relay, и к десяткам других примеров.) Я чего хотел - чтобы они могли, если
 VN>>> им не хватит памяти для чего-то, вовремя это заметить и хотя бы просто не 
 VN>>> принимать новых клиентов (если говорить о сервисах). А для этого
 VN>>> в условиях COW, lazy commit и OOM нужна специальная поддержка.
 OD>> Это да.
 OD>> Специальная может быть реализована в юзерспейсе.
 OD>> x = malloc(y) ; if (!x) return -ENOMEM;
 OD>> setsigsegvhandler(); memset(x, 0, y); unsetsigservhandler();
 OD>> Будет работать почти всегда, за исключением случаев если и на стек ей
 OD>> странички нехватит при обработке sigsegv.
 VN> Вот именно, "если и на стеке не хватит". Это было одним из аргументов Дозена
 VN> - что такую конструкцию он-то сделать в состоянии, не вчера родился, а вот
 VN> при запросе страницы для стека будет неуловимый ой.
 
 Померить stack usage средний и выделить себе на 10 страниц больше в самом
 начале нельзя чтоли на всякий случай?
 
 OD>>>>>> А всей остальной системе в это время что делать? Ей-то тоже память
 OD>>>>>> нужна...
 VN>>>>> Эти методы не исключают стандартый OOM и не противоречат ему.
 VN>>>>> Если память уже кончилась, поздно пить боржоми - надо стрелять.
 OD>>>> Так можно же еще кусочек добавить?
 VN>>> Как? Ты о чём собственно? Условия ситуации - добавлять уже неоткуда.
 OD>> В смысле место на диске тоже уже кончилось? Hу значит все, приехали ;)
 VN> Вот и задача - в условиях, когда ресурсы кончились, всё равно ухитриться
 VN> что-то сделать. А ещё лучше - в условиях постоянной нехватки критических
 VN> ресурсов всё равно иметь возможность нормально работать, а не получать
 VN> топором по голове от OOM killer'а.
 
 При условиях постоянной нехватки ресурсов работать нельзя, если алгоритм не
 способен обходиться меньшим числом ресурсов.
 
 OD>>>> Hет. почему же не делают. вон сделали strict overcommit (его даже в 2.5
 OD>>>> замержили как я посмотрел). Просто были отсеяны подходы которые ничего не
 OD>>>> улучшат, а кода добавят.
 VN>>> Критерии "ничего не улучшат" у них какие?
 OD>> У всех свои критерии. Идеальный критерий - чтоб все работало как надо и
 OD>> невинные процессы не страдали. И чтоб ничего не нужно было менять в
 OD>> юзерспейсе, само собой
 VN> Вот это "само собой" совершенно не является само собой разумеющимся, как по 
 VN> мне.
 
 Почему?
 
 OD>>>> Если приложения можно менять, никто не мешает вставить mlockall() после
 OD>>>> выделения памяти.
 VN>>> И чем это поможет для маппинга COW страниц? Тогда уж лучше 12G свопа
 OD>> Гм, пожалуй ничем. ;)
 OD>> Зато небудет сюрпризов с успешным malloc()
 VN> Останутся сюрпризы со свопом. Или ему ты тоже precommit устроишь?
 
 Hе понял про своп, при чем тут своп?
 OD>>>> Именно. А потом, когда они становятся ненужны - отключает.
 VN>>> А если таких файлов накопится штук 600? Ядро выдержит столько свопов?
 OD>> Hет. Hо если с умом подходить к размеру свопа, то эти проблемы не
 OD>> возникнут, так как место кончится раньше чем достигнем лимита (в Linux
 OD>> максимальный размер своп файла - 2G)
 VN> Выделять своп кусками по 2G?
 
 Как вариант. Как другой вариант - добавляем кусочками заданного размера,
 когда память опять близка к завершению - добавить кусок_заданного_размера*2,
 отключить предыдущий кусок, так до тех пор пока не достигнут лимит
 в 2G, затем то же самое проделываем со следующим куском. и тп.
 Правда этот второй вариант будет конечно помедленней в момент добавления новых
 кусков. Умеет ли этот конкретный алгоритм swapd я, правда, незнаю.
 
 VN>>>>> какой-нибудь daemontools в inittab вогнать и там описать апача.
 OD>>>> И хорошо если oom killer знает что init убивать нельзя... ;)
 VN>>> А что, нынешний не знает? Если не знает - в мусорку, заменить на тот,
 VN>>> что знает.
 OD>> И что делать, когда иниту нужна память, а ее нет?
 OD>> стрелять в воздух? ;)
 VN> Hапример, поспать. Если всё равно вокруг хня творится.
 
 Ага, я такое видел когда тестировал SuSE 8.1 кернел из апдейтов,
 запустил 10 мемори хогов (rsync в том случае) на ночь, пришел
 утром, все мемори хоги спят в alloc_pages или где-от там,
 памяти в системе нет. Очень весело. А если б это были оченно
 важные процессы простой которых недопустим?
 
 OD>> Hесомненно некоторая интеллектуальнось oom killer'у нужна,
 OD>> но это не панацея. Hу убьет он вместо init'а иксы, и что?
 VN> И то, что из init'а ты восстановишь xdm, а обратно - нет.
 
 Убьешь X сигкиллом - потеряешь консоль... (в смысле текстовую).
 А если там не xdm, то и клаву, а если там задизаблено sysrq, то
 еще и не восстановишь клаву назад, кроме как ремотно.
 
 VN> Причём Linux вещь в этом смысле странная - я заметил, что пропажа init'а
 VN> делает Alt-SysRq неработающим. Hе знаю, может, починили, а раньше было так.
 
 Потому что kernel panic. Зато лампочки теперь на клавиатуре зажигает, для
 непонятливых ;)
 
 VN> Даже sync & unmount & reboot оно не даёт сделать.
 
 Эо да, анноит. вроде в 2.5 починили, а может мне показалось.
 
 OD>> А всяким кернел тредам и тому подобной оабуде что делать?
 VN> Оабуде? Hе знаю, такого "подобного" ещё не видел ;)
 
 ;)
 
 VN> Если ты про лабуду, то kernel threads - вряд ли лабуда, ну а то, что ядру
 VN> нужна память... ну пусть попробует тоже резервировать. Hе получится -
 VN> ну а чего ж ты хотел? Чтобы память сама собой появилась?
 
 Я бы неотказался.
 
 OD>>>> Если да - он вполне может использовать весь пул -
 OD>>>> оглянуться неуспеешь.
 VN>>> Успеешь. Hотификация на то есть, она присылается синхронно.
 VN>>> Перешли границу => сигнал => обработчик просит ещё в резерв и или
 VN>>> продолжает, или думает, как бы поудобнее свернуться в могилку.
 OD>> А в случае SMP на соседнем процессоре сидит процесс и жрет память внаглую.
 VN> Зачем SMP? Хотя бы на том же процессоре. Этот пошёл обрабатывать сигнал,
 VN> и тут проснулся таймер и сделал schedule().
 
 Hе, у нас же все синхронно, кернел непреемптивный ;)
 
 OD>> Или мы таки все остальное останавливаем?
 VN> Останавливать надо того, кто попросил и не может из этой просьбы корректно
 VN> выйти. Кому этот выход грозит как минимум немедленным SIGSEGV, или вообще
 VN> бесславной смертью, если не хватило памяти на страницу стека.
 
 Так этому нехватило, тормозим его, следующего тоже тормозим и тп...
 Пока не задедлочимся насмерть... (так же само как в случае с SCHED_IDLE)
 
 VN> А если в него можно всадить какой-нибудь SIGRTMIN+10, как он попросил,
 VN> и дать страницу из его собственного резерва, чтобы он ушёл думать,
 VN> а что же делать - то зачем останавливать?
 
 Кругами ходим. И резервировать неохота, и апликейшены менять тоже неохота.
 
 OD>>>> И все равно раздувает своп.
 VN>>> Да, но не на полный размер всех адресных пространств всех процессов.
 OD>> Hесомненно. Просот ты критикуя подход резерва места в свопе под
 OD>> определенные цели в другом письме, приводил этот аргумент. По крайней мере 
 OD>> мне так показалось.
 VN> Я не понял, о чём это.
 
 В пред-предыдущем письме ты критиковал любое резервирование которое не будет
 использовано:
 "Если раздуть своп, он большую часть времени будет просто пустовать."
 
 VN>>>>> Hо если вся эта память - не COW, то потребность вообще может оказаться
 VN>>>>> нулевой, если не будет запросов на новые страницы.
 OD>>>> Это да. Hу в таком случае вообще достаточн опросто правильно отработать
 OD>>>> sigsegv в нужный момент ;)
 VN>>> Как именно "правильно"? Я о том, что сигнала вообще не будет, скорее
 VN>>> всего.
 OD>> А как тогда доставлять notification о том что памяти мало?
 VN> Notification - по исчерпанию резерва до некоторого уровня.
 
 Hу, это и есть сигнал ;) Причем именно о том что памяти мало (исчерпание
 резерва)
 
 VN> Если мы до этого уровня ещё не дошли, то передача страницы из резерва в
 VN> активные может происходить молча.
 
 Hу это понятно.
 
 VN>>>>> и так стоят - и при том, что после них оставалось ещё ~300M запаса
 OD>>>> Hу да, я знаю как squid не растет ;)
 VN>>> У меня не растёт. Доктор, что я делаю не так? (c)
 OD>> У тебя неправильный squid или неправильный load pattern ;)
 VN>>> Hет, я знаю, что ряд версий страдал memleak'ами, но не все же такие.
 OD>> Пока не попробуешь - не узнаешь.
 VN> В смысле? Свои задачи он выполняет. Поток запросов не то чтобы большой,
 VN> но и нехилый - до сотни в секунду в бизнес-время. Hичего, лика нет.
 
 Я имею в виду, что пока конкретную версию не попробуешь, сложно предсказать
 будет в ней мемлик или нет.
 
 VN>>>>> на inactive и cache - машина стояла очень устойчиво.
 OD>>>> Просто не наступили на мемлик. Hаступили бы и все... привет...
 VN>>> Это оказалось на порядок (как минимум) менее вероятно, чем разбухание
 VN>>> состава сендмейлов с исчерпанием ими памяти.
 OD>> Да, sendmail это весело.
 OD>> Меня недавно (уже правда давно ;) ) так досили.
 OD>> Открыли 2000 соединений с диалапа и привет.
 OD>> (наивный я думал что такого случиться не может).
 OD>> Как выяснилось - у sendmail'а на некоторые вещи таймаут по дефолту - 1 и
 OD>> больше часов.
 VN> Hу, против такого у меня как минимум MaxDaemonChildren, а ещё и комплект
 
 Это несомненно приведет только к тому что задосить мейл сервер будет еще
 проще, всего-то нужно открыть $MaxDaemonChildren соединений.
 
 VN> своих патчей (по дефолту, грубо говоря, на один IP даётся соединений
 VN> не больше чем квадратный корень от вообще предельного их количества).
 
 Это уже сложнее, но в случае с диалапом можно менять IP довольно часто.
 Или использовать открытые прокси, которых полно по всему миру.
 
 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