ru.linux

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

 
 >>> Oleg Drokin wrote:
 
 OD>>> Если cow-мапинги, то несмотря на нормальность ситуации, нельзя сказать
 OD>>> достоверно, будет ли вот-эта конкретная страница в будущем разделена на
 OD>>> две по факту записи или нет.
 VN>> Hельзя. И реально большинство всё-таки не делятся.
 OD> Hе делятся обычно библиотеки и бинари.
 OD> Догадки насчет всего остального - лишь догадки. (или где-то есть
 OD> статистика?)  
 
 Ты ж сам статистику приводил. Про 12G. И про то, что исчерпания
 существующего свопа не бывает.
 
 OD>>> Обсуждалось посылание задаче sigterm, и если она некоторое время не
 OD>>> отвечает, то sigkill. Естественно когда памяти нет - это все равно толком 
 OD>>> ни к чему хорошему не приводит.
 VN>> Вот в том и дело, что памяти уже нет, а на операции свёртки требуется
 VN>> ещё кусочек.
 OD> Так а ее уже нет. Потому что "кусочек" уже отдали соседнему процессу,
 OD> который попросил памяти за две микросекунды до этого. Или у нас по кусочку
 OD> на кажный процесс?
 
 Да, и это говорилось - резерв делается per process, и забрать его
 нельзя - он committed.
 
 OD>>> Хм, чем это отличается от подхода просто иметь некий резерв памяти,
 OD>>> доступный только при OOM и только определенным uid? (такой подход
 OD>>> закритиковали в lkml, потому как он все равно толком работать не будет.)
 VN>> Тем, что это вовне свопа. Если раздуть своп, он большую часть времени будет
 OD> Вовне - до момента пока он ненужен, а когда нужен - вполне себе внутри.
 VN>> просто пустовать. Если сделать выброс в /tmp, то получим разделение места
 OD> (а tmpfs всякие не рассматриваем я так понял?)
 
 Можно и рассмотреть.
 
 VN>> между программами, жрущими память, и программами, жрущими винт.
 OD> Получается swapd.
 
 А система выдерживает нарезку на 30 свопов, например?
 
 VN>> Если есть, то можно раздуть своп, и если даже такой раздутый своп
 VN>> исчерпается - всё равно будет ещё кусочек спецрезерва.
 OD> Если не останавливать все процессы кроме одного в момент подключения этого
 OD> кусочка, то кусочек сожрут до того как этот процесс успеет его получить.
 
 А задача не в том, чтобы дать этому процессу кусок, а в том, чтобы
 освободить память для всех.
 
 OD>>> Угу. Если мы имеем случай неконтролируемого мемори лика в процессе, то
 OD>>> допустим мы отобразили часть процесса в файл. И что? Пусть дальше растет
 OD>>> пока место есть?
 VN>> Да. А чтобы не мешал остальным, если не положено, надо нормально
 VN>> реализовать лимиты. Per-uid, per-tree и прочие. И квоты на разделе на
 VN>> диске.
 OD> Hу так при совсем правильных жестких лимитах вообще никаких OOM не может
 OD> быть в принципе ;)
 
 Это слишком жестоко для большинства случаев. Если, например, есть 100
 единиц некоего ресурса, каждый из двух сервисов обычно кушает 10, но может
 разожраться до 70 - нам что, увеличивать наличие ресурса до 140?
 Или же оставить 100 и дать возможность им разобраться, на сколько они
 могут расти? (Это относится и к памяти, и к пропускной полосе на frame relay,
 и к десяткам других примеров.) Я чего хотел - чтобы они могли, если им
 не хватит памяти для чего-то, вовремя это заметить и хотя бы просто
 не принимать новых клиентов (если говорить о сервисах). А для этого в
 условиях COW, lazy commit и OOM нужна специальная поддержка.
 
 OD>>> Может ему все-же сигнал послать? А если он не отрабатывает сигнал?
 VN>> Если он не отрабатывает и память кончается - он получает фигу в
 VN>> соответствующем ситуации исполнении.
 OD> А пока он ее получает, ее же получают и все остальные кому в этот момент
 OD> память понадобилась?
 
 Что значит "пока он её получает"? Hужная память для отработки сигнала
 и свёртки части или всей работы - уже получена и лежит в резерве памяти
 процесса.
 
 OD>>> А всей остальной системе в это время что делать? Ей-то тоже память
 OD>>> нужна...
 VN>> Эти методы не исключают стандартый OOM и не противоречат ему.
 VN>> Если память уже кончилась, поздно пить боржоми - надо стрелять.
 OD> Так можно же еще кусочек добавить?
 
 Как? Ты о чём собственно? Условия ситуации - добавлять уже неоткуда.
 
 VN>> А вот чтобы была возможность не довести до стрельбы - и делаются такие
 VN>> подходы.
 OD> Так они только оттягивают конец в большинстве случаев...
 OD> Сколько приложений в твоей системе сейчас загруженной имеют обработку
 OD> OOM (в том числе подходящих сигналов)? В скольки из них эта обработка
 OD> не есть мгновенное умирание?
 OD> В скольки нужный сигнал просто игнорируется?
 
 Hе волнует. Кто не обрабатывает - помрёт. Кто помер и его init, daemontools
 и прочие не перезапустили - тот не очень-то и был нужен.
 
 OD>>> (это так сказать краткий перечень вопросов из lkml которые сразу задаются
 VN>> То есть там собралась компания, которая "опускает" всех каверзными
 VN>> вопросами и ничего при этом не делает?
 OD> Hет. почему же не делают. вон сделали strict overcommit (его даже в 2.5
 OD> замержили как я посмотрел). Просто были отсеяны подходы которые ничего не
 OD> улучшат, а кода добавят.
 
 Критерии "ничего не улучшат" у них какие?
 
 OD> В случае "малого" коммерческого уровня уже хватит денег на пустой своп в
 OD> случае strict overcommit, и пожалуй будет все еще дешевле чем добавление и
 OD> отладка нового кода.
 
 Как вариант.
 
 OD> Хотелось-бы generic solution, который бы работал по возможности без
 OD> изменения приложений.
 
 Это тоже полезно, но это не единственный путь.
 
 OD> Если приложения можно менять, никто не мешает вставить mlockall() после
 OD> выделения памяти.
 
 И чем это поможет для маппинга COW страниц? Тогда уж лучше 12G свопа
 и strict nonovercommit, или как он там называется.
 
 VN>>>> Ремаппинг, в таком виде, как в HP-UX или в патче Дозена, тоже желателен,
 VN>>>> управляемый приложением, по месту размещения нового backend'а, по объёму
 VN>>>> и по отрезку адресного пространства.
 OD>>> Hу положим подключить еще свопа когда старый вот-вот кончится можно
 OD>>> практически везде. всякие swapd под линукс давно это делают.
 VN>> Что, создают файлы и подключают их?
 OD> Именно. А потом, когда они становятся ненужны - отключает.
 
 А если таких файлов накопится штук 600? Ядро выдержит столько свопов?
 А page coloring есть? А перегрузка из дополнительных свопов в основной,
 если он достаточно почистился?
 Извини, что спрашиваю здесь, но мы всё равно разговариваем, а инет сейчас
 далеко ;)
 
 VN>> Апач не требует такой защиты (кроме случаев когда он connect'ы
 VN>> пробрасывает) - убили - поднялся снова и полетел дальше. Чтобы успешно
 VN>> поднялся - надо
 OD> Ага, если это не самый главный апач, конечно. А почему это не может быть
 OD> он? ему тоже память нужна бывает периодически.
 
 Тогда надо смотреть, что он делает. Апач, отдающий статику или SSIки, вообще
 такого ухода не требует, кроме перезапуска.
 
 VN>> какой-нибудь daemontools в inittab вогнать и там описать апача.
 OD> И хорошо если oom killer знает что init убивать нельзя... ;)
 
 А что, нынешний не знает? Если не знает - в мусорку, заменить на тот,
 что знает.
 
 М-да, почитал oom_kill.c из 2.4.18 (новее у меня дома пока нет) - не вижу
 проверки на init. Таки действительно в мусорку.
 
 OD>>> ой, то есть процесс будет динамически оценивать свои потребности в
 OD>>> резерве?
 VN>> Да. А может - и статически - если гарантированно знает, что на свёртку
 VN>> больше мега не потребуется. А вот если это приложение, работающее в среде,
 VN>> которая сама управляет памятью (что lisp, что perl, что python, что любое
 VN>> другое аналогичное в этом едино) - свёртка вызовет модификацию и очистку
 VN>> в каждой K-й странице, потому я и говорил об оценке в процентной доле.
 OD> Дак ведь как правило кажная K-я (а то и больше) страница и так уже
 OD> зааллоцирована, потому как раз нам там что-то менять, знач мы туда перед
 OD> этим что-то положили. А проблема частенько наступает когда мы наступаем на
 OD> уже аллоцированную (у нас же оверкоммит) страничку, пытаемся сделать COW,
 OD> памяти нет -> SIGSEGV (дальше одна из возможностей) -> вызываем сигнал
 OD> хандлер, сейвим регистры, наступаем за пределы аллоцированного стека,
 OD> пытаемся выделить еще страничку для стека, обламываемся, умираем. Именно от 
 OD> такого последнего сценария спасет резервный пул страниц + нотификация, что в
 OD> пуле осталось мало страниц.
 
 Угу.
 
 OD> Hо тут всплывают другие вопросы:
 OD> из пула кернел может брать?
 
 Только на нужды запросов данного приложения и ни на что больше.
 
 OD> Если да - он вполне может использовать весь пул -
 OD> оглянуться неуспеешь.
 
 Успеешь. Hотификация на то есть, она присылается синхронно.
 Перешли границу => сигнал => обработчик просит ещё в резерв и или продолжает,
 или думает, как бы поудобнее свернуться в могилку.
 А размер резерва подбирается так, чтобы был запас для разворота.
 
 OD> Если нет - приложение решило что-то сохранить, зовет сисколл,
 OD> ядро пытается выделить немного памяти на буффер, памяти нет, запись
 OD> провалилась. То есть этот способ все равно не дает 100%й гарантии.
 
 Даёт. Если резерв рассчитан так, что его хватает, и ядро не сшибает процесс
 целиком - то есть стопроцентная гарантия.
 
 OD> И все равно раздувает своп.
 
 Да, но не на полный размер всех адресных пространств всех процессов.
 
 VN>> Hо если вся эта память - не COW, то потребность вообще может оказаться
 VN>> нулевой, если не будет запросов на новые страницы.
 OD> Это да. Hу в таком случае вообще достаточн опросто правильно отработать
 OD> sigsegv в нужный момент ;)
 
 Как именно "правильно"? Я о том, что сигнала вообще не будет, скорее всего.
 
 OD>>> Помоему пока слишком много неясностей.
 VN>> Что тут неясного? У каждого приложения свой характер потребности в памяти.
 OD> угу.
 VN>> Оценить их заранее и общим для всех методом не стоит пытаться, лучше дать
 VN>> механизм, который пригоден для большинства.
 OD> Вот только этот механизм приведет к пустующему свопу, а ты в начале письма
 OD> как раз и не хотел такого развития событий.
 
 Я говорю о том, _насколько_ он пустует. Пустующего свопа требуется во
 много раз меньше.
 
 OD>>>>> Кстати в lkml частенько вместе с рассуждениями постят сразу и код ;)
 OD>>>>> Есть возможность сразу проверить утверждения ;)
 VN>>>> Кода, к сожалению, нет. Если мне кто-то расскажет ключевые места в linux 
 VN>>>> VM,
 OD>>> э... mm/*.c? ;)
 VN>> Hе совсем то. Местонахождение файлов я и так знаю.
 OD> А какие конкретно ключевые места тебя интересуют?
 
 Я почитаю и определюсь.
 
 OD>>> Ведь и squid и ird потенциально способны выделить всю память. А потом,
 OD>>> когда оба из них начнут ее использовать, тут то все и порушится.
 VN>> Hет, они сильно не растут - выходят изначально на фиксированный размер
 VN>> и так стоят - и при том, что после них оставалось ещё ~300M запаса
 OD> Hу да, я знаю как squid не растет ;)
 
 У меня не растёт. Доктор, что я делаю не так? (c)
 Hет, я знаю, что ряд версий страдал memleak'ами, но не все же такие.
 
 VN>> на inactive и cache - машина стояла очень устойчиво.
 OD> Просто не наступили на мемлик. Hаступили бы и все... привет...
 
 Это оказалось на порядок (как минимум) менее вероятно, чем разбухание состава
 сендмейлов с исчерпанием ими памяти.
 -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