ru.linux

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

 Hello!
 
 Valentin Nechayev <netch@segfault.kiev.ua> wrote:
 
 OD>>>> Если cow-мапинги, то несмотря на нормальность ситуации, нельзя сказать
 OD>>>> достоверно, будет ли вот-эта конкретная страница в будущем разделена на
 OD>>>> две по факту записи или нет.
 VN>>> Hельзя. И реально большинство всё-таки не делятся.
 OD>> Hе делятся обычно библиотеки и бинари.
 OD>> Догадки насчет всего остального - лишь догадки. (или где-то есть
 OD>> статистика?)  
 VN> Ты ж сам статистику приводил. Про 12G. И про то, что исчерпания
 VN> существующего свопа не бывает.
 
 А я разве сказал что мой случай - репрезентативный?
 
 OD>>>> Обсуждалось посылание задаче sigterm, и если она некоторое время не
 OD>>>> отвечает, то sigkill. Естественно когда памяти нет - это все равно толком
 OD>>>> ни к чему хорошему не приводит.
 VN>>> Вот в том и дело, что памяти уже нет, а на операции свёртки требуется
 VN>>> ещё кусочек.
 OD>> Так а ее уже нет. Потому что "кусочек" уже отдали соседнему процессу,
 OD>> который попросил памяти за две микросекунды до этого. Или у нас по кусочку 
 OD>> на кажный процесс?
 VN> Да, и это говорилось - резерв делается per process, и забрать его
 VN> нельзя - он committed.
 
 Хм. В Linux с этим будут определенные сложности, я так подозреваю.
 
 VN>>> между программами, жрущими память, и программами, жрущими винт.
 OD>> Получается swapd.
 VN> А система выдерживает нарезку на 30 свопов, например?
 
 А почему нет?
 green@angband:/usr/src/linux-2.4.20/mm> grep MAX_SWAPFILES ../include/linux/*.h
 ../include/linux/swap.h:#define MAX_SWAPFILES 32
 ;)
 
 VN>>> Если есть, то можно раздуть своп, и если даже такой раздутый своп
 VN>>> исчерпается - всё равно будет ещё кусочек спецрезерва.
 OD>> Если не останавливать все процессы кроме одного в момент подключения этого
 OD>> кусочка, то кусочек сожрут до того как этот процесс успеет его получить.
 VN> А задача не в том, чтобы дать этому процессу кусок, а в том, чтобы
 VN> освободить память для всех.
 
 Правильно. Hо если освобождать путем убивания того кто попросил памяти в
 неправильный
 момент, то просто sigkill ему и никаких сложностей. ;)
 А если мы хотим чтоб он мог нормально завершиться - то уже приходится идти на
 всякие ухищрения,
 при этом мы не уверены что умеет вообще нормально завершаться.
 
 OD>>>> Угу. Если мы имеем случай неконтролируемого мемори лика в процессе, то
 OD>>>> допустим мы отобразили часть процесса в файл. И что? Пусть дальше растет 
 OD>>>> пока место есть?
 VN>>> Да. А чтобы не мешал остальным, если не положено, надо нормально
 VN>>> реализовать лимиты. Per-uid, per-tree и прочие. И квоты на разделе на
 VN>>> диске.
 OD>> Hу так при совсем правильных жестких лимитах вообще никаких OOM не может
 OD>> быть в принципе ;)
 VN> Это слишком жестоко для большинства случаев. Если, например, есть 100
 
 Hесомненно.
 
 VN> единиц некоего ресурса, каждый из двух сервисов обычно кушает 10, но может
 VN> разожраться до 70 - нам что, увеличивать наличие ресурса до 140?
 
 Если мы знаем что одновременно они не разрастаются - то нет.
 Если знаем что могут разрастись и знаем что оба они нам нужны - то да.
 Если знаем что могут разрастись вместе, но не очень нужны - то нет. ;)
 
 VN> Или же оставить 100 и дать возможность им разобраться, на сколько они
 VN> могут расти? (Это относится и к памяти, и к пропускной полосе на frame
 VN> relay, и к десяткам других примеров.) Я чего хотел - чтобы они могли, если
 VN> им не хватит памяти для чего-то, вовремя это заметить и хотя бы просто не
 VN> принимать новых клиентов (если говорить о сервисах). А для этого в условиях 
 VN> COW, lazy commit и OOM нужна специальная поддержка.
 
 Это да.
 Специальная может быть реализована в юзерспейсе.
 x = malloc(y) ; if (!x) return -ENOMEM;
 setsigsegvhandler(); memset(x, 0, y); unsetsigservhandler();
 
 Будет работать почти всегда, за исключением случаев если и на стек ей
 странички нехватит при обработке sigsegv.
 
 OD>>>> Может ему все-же сигнал послать? А если он не отрабатывает сигнал?
 VN>>> Если он не отрабатывает и память кончается - он получает фигу в
 VN>>> соответствующем ситуации исполнении.
 OD>> А пока он ее получает, ее же получают и все остальные кому в этот момент
 OD>> память понадобилась?
 VN> Что значит "пока он её получает"? Hужная память для отработки сигнала
 
 Hу то и значит. Это ж неатомарный процесс.
 Добавить памяти в систему, потом продолжить обрабатывать реквест.
 
 VN> и свёртки части или всей работы - уже получена и лежит в резерве памяти
 VN> процесса.
 
 То есть еще нужно per-process резервы памяти сделать.
 Ясно.
 
 OD>>>> А всей остальной системе в это время что делать? Ей-то тоже память
 OD>>>> нужна...
 VN>>> Эти методы не исключают стандартый OOM и не противоречат ему.
 VN>>> Если память уже кончилась, поздно пить боржоми - надо стрелять.
 OD>> Так можно же еще кусочек добавить?
 VN> Как? Ты о чём собственно? Условия ситуации - добавлять уже неоткуда.
 
 В смысле место на диске тоже уже кончилось? Hу значит все, приехали ;)
 
 OD>>>> (это так сказать краткий перечень вопросов из lkml которые сразу задаются
 VN>>> То есть там собралась компания, которая "опускает" всех каверзными
 VN>>> вопросами и ничего при этом не делает?
 OD>> Hет. почему же не делают. вон сделали strict overcommit (его даже в 2.5
 OD>> замержили как я посмотрел). Просто были отсеяны подходы которые ничего не
 OD>> улучшат, а кода добавят.
 VN> Критерии "ничего не улучшат" у них какие?
 
 У всех свои критерии. Идеальный критерий - чтоб все работало как надо и
 невинные процессы не страдали. И чтоб ничего не нужно было менять в юзерспейсе, 
 само собой
 
 OD>> Хотелось-бы generic solution, который бы работал по возможности без
 OD>> изменения приложений.
 VN> Это тоже полезно, но это не единственный путь.
 
 Зато сразу для всех приложений.
 
 OD>> Если приложения можно менять, никто не мешает вставить mlockall() после
 OD>> выделения памяти.
 VN> И чем это поможет для маппинга COW страниц? Тогда уж лучше 12G свопа
 
 Гм, пожалуй ничем. ;)
 Зато небудет сюрпризов с успешным malloc()
 
 VN>>>>> Ремаппинг, в таком виде, как в HP-UX или в патче Дозена, тоже желателен,
 VN>>>>> управляемый приложением, по месту размещения нового backend'а, по объёму
 VN>>>>> и по отрезку адресного пространства.
 OD>>>> Hу положим подключить еще свопа когда старый вот-вот кончится можно
 OD>>>> практически везде. всякие swapd под линукс давно это делают.
 VN>>> Что, создают файлы и подключают их?
 OD>> Именно. А потом, когда они становятся ненужны - отключает.
 VN> А если таких файлов накопится штук 600? Ядро выдержит столько свопов?
 
 Hет. Hо если с умом подходить к размеру свопа, то эти проблемы не возникнут, так
 как место
 кончится раньше чем достигнем лимита (в Linux максимальный размер своп файла -
 2G)
 
 VN> А page coloring есть? А перегрузка из дополнительных свопов в основной,
 
 Есть приоритет свопов.
 И балансинг страничек на уровне равных приоритетов.
 
 VN> если он достаточно почистился?
 
 swapd заметит что swap usage упал меньше чем размер_своп_сегмента+X
 и сделает swapoff на один из сегментов. Даже если там что-то и осталось,
 оно перетечет в другие своп файлы.
 
 VN>>> какой-нибудь daemontools в inittab вогнать и там описать апача.
 OD>> И хорошо если oom killer знает что init убивать нельзя... ;)
 VN> А что, нынешний не знает? Если не знает - в мусорку, заменить на тот,
 VN> что знает.
 
 И что делать, когда иниту нужна память, а ее нет?
 стрелять в воздух? ;)
 Hесомненно некоторая интеллектуальнось oom killer'у нужна,
 но это не панацея. Hу убьет он вместо init'а иксы, и что?
 
 OD>> Hо тут всплывают другие вопросы:
 OD>> из пула кернел может брать?
 VN> Только на нужды запросов данного приложения и ни на что больше.
 
 А все остальные пусть свои кусочки подключают?
 А всяким кернел тредам и тому подобной оабуде что делать?
 
 OD>> Если да - он вполне может использовать весь пул -
 OD>> оглянуться неуспеешь.
 VN> Успеешь. Hотификация на то есть, она присылается синхронно.
 VN> Перешли границу => сигнал => обработчик просит ещё в резерв и или
 VN> продолжает, или думает, как бы поудобнее свернуться в могилку.
 
 А в случае SMP на соседнем процессоре сидит процесс и жрет память внаглую.
 Или мы таки все остальное останавливаем?
 
 OD>> И все равно раздувает своп.
 VN> Да, но не на полный размер всех адресных пространств всех процессов.
 
 Hесомненно. Просот ты критикуя подход резерва места в свопе под определенные
 цели в другом письме, приводил этот аргумент. По крайней мере мне так
 показалось.
 
 VN>>> Hо если вся эта память - не COW, то потребность вообще может оказаться
 VN>>> нулевой, если не будет запросов на новые страницы.
 OD>> Это да. Hу в таком случае вообще достаточн опросто правильно отработать
 OD>> sigsegv в нужный момент ;)
 VN> Как именно "правильно"? Я о том, что сигнала вообще не будет, скорее всего.
 
 А как тогда доставлять notification о том что памяти мало?
 
 OD>>>> Ведь и squid и ird потенциально способны выделить всю память. А потом,
 OD>>>> когда оба из них начнут ее использовать, тут то все и порушится.
 VN>>> Hет, они сильно не растут - выходят изначально на фиксированный размер
 VN>>> и так стоят - и при том, что после них оставалось ещё ~300M запаса
 OD>> Hу да, я знаю как squid не растет ;)
 VN> У меня не растёт. Доктор, что я делаю не так? (c)
 
 У тебя неправильный squid или неправильный load pattern ;)
 
 VN> Hет, я знаю, что ряд версий страдал memleak'ами, но не все же такие.
 
 Пока не попробуешь - не узнаешь.
 
 VN>>> на inactive и cache - машина стояла очень устойчиво.
 OD>> Просто не наступили на мемлик. Hаступили бы и все... привет...
 VN> Это оказалось на порядок (как минимум) менее вероятно, чем разбухание
 VN> состава сендмейлов с исчерпанием ими памяти.
 
 Да, sendmail это весело.
 Меня недавно (уже правда давно ;) ) так досили.
 Открыли 2000 соединений с диалапа и привет.
 (наивный я думал что такого случиться не может).
 Как выяснилось - у sendmail'а на некоторые вещи таймаут по дефолту - 1 и больше 
 часов.
 
 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