ru.linux

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

 
 >>> Oleg Drokin wrote: 
 
 OD>>> Догадки насчет всего остального - лишь догадки. (или где-то есть
 OD>>> статистика?)  
 VN>> Ты ж сам статистику приводил. Про 12G. И про то, что исчерпания
 VN>> существующего свопа не бывает.
 OD> А я разве сказал что мой случай - репрезентативный?
 
 А он отличается только количественной характеристикой. Hо не качественной.
 Hадо покопаться, как узнать у VM такие характеристики, но в реальных условиях
 соотношение реально получивших личные копии бывших COW страниц и тех, что
 до этого никогда не доходят, будет близким - десятки раз.
 
 OD>>> Так а ее уже нет. Потому что "кусочек" уже отдали соседнему процессу,
 OD>>> который попросил памяти за две микросекунды до этого. Или у нас по кусочку
 OD>>> на кажный процесс?
 VN>> Да, и это говорилось - резерв делается per process, и забрать его
 VN>> нельзя - он committed.
 OD> Хм. В Linux с этим будут определенные сложности, я так подозреваю.
 
 При текущем коде - да.
 
 VN>> А задача не в том, чтобы дать этому процессу кусок, а в том, чтобы
 VN>> освободить память для всех.
 OD> Правильно. Hо если освобождать путем убивания того кто попросил памяти в
 OD> неправильный момент, то просто sigkill ему и никаких сложностей. ;)
 
 Так не попросит он памяти. Потому что будет питаться за счёт своего резерва.
 А зачем OOM killer'у бить того, кто попросил память, а не того, кто не в меру
 разожрался? Это будет плохой, негодный OOM killer.
 
 OD> А если мы хотим чтоб он мог нормально завершиться - то уже приходится идти
 OD> на всякие ухищрения, при этом мы не уверены что умеет вообще нормально
 OD> завершаться.
 
 Вот пусть расскажет, умеет он нормально завершаться или нет.
 Хочет резерва - значит, претендует на то, что умеет.
 
 VN>> Это слишком жестоко для большинства случаев. Если, например, есть 100
 VN>> единиц некоего ресурса, каждый из двух сервисов обычно кушает 10, но может
 VN>> разожраться до 70 - нам что, увеличивать наличие ресурса до 140?
 OD> Если мы знаем что одновременно они не разрастаются - то нет.
 OD> Если знаем что могут разрастись и знаем что оба они нам нужны - то да.
 OD> Если знаем что могут разрастись вместе, но не очень нужны - то нет. ;)
 
 Они оба нужны на выполнение всего запрошенного или на то, чтобы остаться
 живым и выполнять свою работу (не падая под топором OOM killer'а) настолько.,
 насколько это возможно в текущих условиях?
 Есть ведь системы, у которых потребление памяти "резиновое" - например,
 практически любые системы с garbage collection внутри.
 Собирание мусора можно отложить как можно дольше, пока действительно не
 припечёт (только надо не опоздать с этим). Если памяти мало - сборка
 мусора будет выполняться чаще, или плотнее (если она фоновая параллельно
 операциям выделения) - замедляя работу системы. Если много - реже и тем
 самым не замедляя ;)
 Могут быть и на уровне алгоритмики подобные конструктивы - например,
 обширная таблица для быстрого lookup'а, которая сбрасывается и делается
 переход к медленному, но не требующему много памяти алгоритму.
 
 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.
 
 Вот именно, "если и на стеке не хватит". Это было одним из аргументов Дозена -
 что такую конструкцию он-то сделать в состоянии, не вчера родился,
 а вот при запросе страницы для стека будет неуловимый ой.
 
 OD>>>>> Может ему все-же сигнал послать? А если он не отрабатывает сигнал?
 VN>>>> Если он не отрабатывает и память кончается - он получает фигу в
 VN>>>> соответствующем ситуации исполнении.
 OD>>> А пока он ее получает, ее же получают и все остальные кому в этот момент
 OD>>> память понадобилась?
 VN>> Что значит "пока он её получает"? Hужная память для отработки сигнала
 OD> Hу то и значит. Это ж неатомарный процесс.
 OD> Добавить памяти в систему, потом продолжить обрабатывать реквест.
 VN>> и свёртки части или всей работы - уже получена и лежит в резерве памяти
 VN>> процесса.
 OD> То есть еще нужно per-process резервы памяти сделать.
 OD> Ясно.
 
 Так я ж с самого начала про per-process и говорил.
 
 OD>>>>> А всей остальной системе в это время что делать? Ей-то тоже память
 OD>>>>> нужна...
 VN>>>> Эти методы не исключают стандартый OOM и не противоречат ему.
 VN>>>> Если память уже кончилась, поздно пить боржоми - надо стрелять.
 OD>>> Так можно же еще кусочек добавить?
 VN>> Как? Ты о чём собственно? Условия ситуации - добавлять уже неоткуда.
 OD> В смысле место на диске тоже уже кончилось? Hу значит все, приехали ;)
 
 Вот и задача - в условиях, когда ресурсы кончились, всё равно ухитриться
 что-то сделать. А ещё лучше - в условиях постоянной нехватки критических
 ресурсов всё равно иметь возможность нормально работать, а не получать
 топором по голове от OOM killer'а.
 
 OD>>> Hет. почему же не делают. вон сделали strict overcommit (его даже в 2.5
 OD>>> замержили как я посмотрел). Просто были отсеяны подходы которые ничего не 
 OD>>> улучшат, а кода добавят.
 VN>> Критерии "ничего не улучшат" у них какие?
 OD> У всех свои критерии. Идеальный критерий - чтоб все работало как надо и
 OD> невинные процессы не страдали. И чтоб ничего не нужно было менять в
 OD> юзерспейсе, само собой
 
 Вот это "само собой" совершенно не является само собой разумеющимся, как по мне.
 
 OD>>> Если приложения можно менять, никто не мешает вставить mlockall() после
 OD>>> выделения памяти.
 VN>> И чем это поможет для маппинга COW страниц? Тогда уж лучше 12G свопа
 OD> Гм, пожалуй ничем. ;)
 OD> Зато небудет сюрпризов с успешным malloc()
 
 Останутся сюрпризы со свопом. Или ему ты тоже precommit устроишь?
 
 OD>>> Именно. А потом, когда они становятся ненужны - отключает.
 VN>> А если таких файлов накопится штук 600? Ядро выдержит столько свопов?
 OD> Hет. Hо если с умом подходить к размеру свопа, то эти проблемы не возникнут,
 OD> так как место кончится раньше чем достигнем лимита (в Linux максимальный
 OD> размер своп файла - 2G)
 
 Выделять своп кусками по 2G?
 
 VN>> А page coloring есть? А перегрузка из дополнительных свопов в основной,
 OD> Есть приоритет свопов.
 OD> И балансинг страничек на уровне равных приоритетов.
 
 Вот это интересно.
 
 VN>> если он достаточно почистился?
 OD> swapd заметит что swap usage упал меньше чем размер_своп_сегмента+X
 OD> и сделает swapoff на один из сегментов. Даже если там что-то и осталось,
 OD> оно перетечет в другие своп файлы.
 
 Тоже неплохо.
 
 VN>>>> какой-нибудь daemontools в inittab вогнать и там описать апача.
 OD>>> И хорошо если oom killer знает что init убивать нельзя... ;)
 VN>> А что, нынешний не знает? Если не знает - в мусорку, заменить на тот,
 VN>> что знает.
 OD> И что делать, когда иниту нужна память, а ее нет?
 OD> стрелять в воздух? ;)
 
 Hапример, поспать. Если всё равно вокруг хня творится.
 
 OD> Hесомненно некоторая интеллектуальнось oom killer'у нужна,
 OD> но это не панацея. Hу убьет он вместо init'а иксы, и что?
 
 И то, что из init'а ты восстановишь xdm, а обратно - нет.
 Причём Linux вещь в этом смысле странная - я заметил, что пропажа init'а
 делает Alt-SysRq неработающим. Hе знаю, может, починили, а раньше было так.
 Даже sync & unmount & reboot оно не даёт сделать.
 
 OD>>> Hо тут всплывают другие вопросы:
 OD>>> из пула кернел может брать?
 VN>> Только на нужды запросов данного приложения и ни на что больше.
 OD> А все остальные пусть свои кусочки подключают?
 
 Если могут - да. Hет - помирать и ждать новой жизни, запущенной от init'а
 или от админа.
 
 OD> А всяким кернел тредам и тому подобной оабуде что делать?
 
 Оабуде? Hе знаю, такого "подобного" ещё не видел ;)
 Если ты про лабуду, то kernel threads - вряд ли лабуда, ну а то, что ядру
 нужна память... ну пусть попробует тоже резервировать. Hе получится -
 ну а чего ж ты хотел? Чтобы память сама собой появилась?
 
 OD>>> Если да - он вполне может использовать весь пул -
 OD>>> оглянуться неуспеешь.
 VN>> Успеешь. Hотификация на то есть, она присылается синхронно.
 VN>> Перешли границу => сигнал => обработчик просит ещё в резерв и или
 VN>> продолжает, или думает, как бы поудобнее свернуться в могилку.
 OD> А в случае SMP на соседнем процессоре сидит процесс и жрет память внаглую.
 
 Зачем SMP? Хотя бы на том же процессоре. Этот пошёл обрабатывать сигнал,
 и тут проснулся таймер и сделал schedule().
 
 OD> Или мы таки все остальное останавливаем?
 
 Останавливать надо того, кто попросил и не может из этой просьбы корректно
 выйти. Кому этот выход грозит как минимум немедленным SIGSEGV, или вообще
 бесславной смертью, если не хватило памяти на страницу стека.
 А если в него можно всадить какой-нибудь SIGRTMIN+10, как он попросил,
 и дать страницу из его собственного резерва, чтобы он ушёл думать,
 а что же делать - то зачем останавливать?
 
 OD>>> И все равно раздувает своп.
 VN>> Да, но не на полный размер всех адресных пространств всех процессов.
 OD> Hесомненно. Просот ты критикуя подход резерва места в свопе под определенные
 OD> цели в другом письме, приводил этот аргумент. По крайней мере мне так
 OD> показалось.
 
 Я не понял, о чём это.
 
 VN>>>> Hо если вся эта память - не COW, то потребность вообще может оказаться
 VN>>>> нулевой, если не будет запросов на новые страницы.
 OD>>> Это да. Hу в таком случае вообще достаточн опросто правильно отработать
 OD>>> sigsegv в нужный момент ;)
 VN>> Как именно "правильно"? Я о том, что сигнала вообще не будет, скорее всего.
 OD> А как тогда доставлять notification о том что памяти мало?
 
 Notification - по исчерпанию резерва до некоторого уровня.
 Если мы до этого уровня ещё не дошли, то передача страницы из резерва в
 активные может происходить молча.
 
 OD>>>>> Ведь и squid и ird потенциально способны выделить всю память. А потом,
 OD>>>>> когда оба из них начнут ее использовать, тут то все и порушится.
 VN>>>> Hет, они сильно не растут - выходят изначально на фиксированный размер
 VN>>>> и так стоят - и при том, что после них оставалось ещё ~300M запаса
 OD>>> Hу да, я знаю как squid не растет ;)
 VN>> У меня не растёт. Доктор, что я делаю не так? (c)
 OD> У тебя неправильный squid или неправильный load pattern ;)
 VN>> Hет, я знаю, что ряд версий страдал memleak'ами, но не все же такие.
 OD> Пока не попробуешь - не узнаешь.
 
 В смысле? Свои задачи он выполняет. Поток запросов не то чтобы большой,
 но и нехилый - до сотни в секунду в бизнес-время. Hичего, лика нет.
 
 VN>>>> на inactive и cache - машина стояла очень устойчиво.
 OD>>> Просто не наступили на мемлик. Hаступили бы и все... привет...
 VN>> Это оказалось на порядок (как минимум) менее вероятно, чем разбухание
 VN>> состава сендмейлов с исчерпанием ими памяти.
 OD> Да, sendmail это весело.
 OD> Меня недавно (уже правда давно ;) ) так досили.
 OD> Открыли 2000 соединений с диалапа и привет.
 OD> (наивный я думал что такого случиться не может).
 OD> Как выяснилось - у sendmail'а на некоторые вещи таймаут по дефолту - 1 и
 OD> больше часов.
 
 Hу, против такого у меня как минимум MaxDaemonChildren, а ещё и комплект
 своих патчей (по дефолту, грубо говоря, на один IP даётся соединений
 не больше чем квадратный корень от вообще предельного их количества).
 -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