ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Oleg Drokin                          2:5020/400     26 Feb 2003  18:21:44
 To : Valentin Nechayev
 Subject : Re: Swap
 -------------------------------------------------------------------------------- 
 

 Hello!
 
 Valentin Nechayev <netch@segfault.kiev.ua> wrote:
 
 OD>> Если cow-мапинги, то несмотря на нормальность ситуации, нельзя сказать
 OD>> достоверно, будет ли вот-эта конкретная страница в будущем разделена на две
 OD>> по факту записи или нет.
 VN> Hельзя. И реально большинство всё-таки не делятся.
 
 Hе делятся обычно библиотеки и бинари.
 Догадки насчет всего остального - лишь догадки. (или где-то есть статистика?)  
 
 VN>>> Ладно, я перескажу, чего мы там надумали. Изначально Vladimir Dozen
 VN>>> поднял тему вот в каком виде. У него крутится очень толстый сервер
 VN>>> на дофига долгоживущих соединений, каждое из которых требует сложную
 VN>>> и ресурсоёмкую отработку (что-то вроде CORBA proxy).
 VN>>> Хотелось сделать это на linux, но если кончается память, то сшибается
 VN>>> задача целиком, и ей не дают даже пискнуть. "Писк" - аккуратная свёртка
 VN>>> работы -
 OD>> Обсуждалось посылание задаче sigterm, и если она некоторое время не
 OD>> отвечает, то sigkill. Естественно когда памяти нет - это все равно толком
 OD>> ни к чему хорошему не приводит.
 VN> Вот в том и дело, что памяти уже нет, а на операции свёртки требуется
 VN> ещё кусочек.
 
 Так а ее уже нет. Потому что "кусочек" уже отдали соседнему процессу, который
 попросил памяти за две микросекунды до этого.
 Или у нас по кусочку на кажный процесс?
 
 OD>> Хм, чем это отличается от подхода просто иметь некий резерв памяти,
 OD>> доступный только при OOM и только определенным uid? (такой подход
 OD>> закритиковали в lkml, потому как он все равно толком работать не будет.)
 VN> Тем, что это вовне свопа. Если раздуть своп, он большую часть времени будет
 
 Вовне - до момента пока он ненужен, а когда нужен - вполне себе внутри.
 
 VN> просто пустовать. Если сделать выброс в /tmp, то получим разделение места
 
 (а tmpfs всякие не рассматриваем я так понял?)
 
 VN> между программами, жрущими память, и программами, жрущими винт.
 
 Получается swapd.
 
 VN> Если нет одовременно пожирания и теми и теми, получаем удобное разделение
 VN> во времени, как и при обычном использовании /tmp.
 
 А tmpfs - то же самое (разделение), только наоборот ;)
 
 VN> Если есть, то можно раздуть своп, и если даже такой раздутый своп
 VN> исчерпается - всё равно будет ещё кусочек спецрезерва.
 
 Если не останавливать все процессы кроме одного в момент подключения этого
 кусочка, то кусочек сожрут до того как этот процесс успеет его получить.
 
 VN>>> настройка, но в общем в каком-то из tmp. Понятно, что это аварийное
 VN>>> средство, и что место на этом tmp тоже может кончиться.
 OD>> Угу. Если мы имеем случай неконтролируемого мемори лика в процессе, то
 OD>> допустим мы отобразили часть процесса в файл. И что? Пусть дальше растет
 OD>> пока место есть?
 VN> Да. А чтобы не мешал остальным, если не положено, надо нормально реализовать
 VN> лимиты. Per-uid, per-tree и прочие. И квоты на разделе на диске.
 
 Hу так при совсем правильных жестких лимитах вообще никаких OOM не может быть в 
 принципе ;)
 
 OD>> Может ему все-же сигнал послать? А если он не отрабатывает сигнал?
 VN> Если он не отрабатывает и память кончается - он получает фигу в
 VN> соответствующем ситуации исполнении.
 
 А пока он ее получает, ее же получают и все остальные кому в этот момент память 
 понадобилась?
 
 OD>> А всей остальной системе в это время что делать? Ей-то тоже память нужна...
 VN> Эти методы не исключают стандартый OOM и не противоречат ему.
 VN> Если память уже кончилась, поздно пить боржоми - надо стрелять.
 
 Так можно же еще кусочек добавить?
 
 VN> А вот чтобы была возможность не довести до стрельбы - и делаются такие
 VN> подходы.
 
 Так они только оттягивают конец в большинстве случаев...
 Сколько приложений в твоей системе сейчас загруженной имеют обработку
 OOM (в том числе подходящих сигналов)? В скольки из них эта обработка
 не есть мгновенное умирание?
 В скольки нужный сигнал просто игнорируется?
 
 OD>> (это так сказать краткий перечень вопросов из lkml которые сразу задаются
 OD>> сторонникам подхода резервировать часть памяти).
 VN> То есть там собралась компания, которая "опускает" всех каверзными вопросами
 VN> и ничего при этом не делает?
 
 Hет. почему же не делают. вон сделали strict overcommit (его даже в 2.5
 замержили
 как я посмотрел).
 Просто были отсеяны подходы которые ничего не улучшат, а кода добавят.
 
 VN>>> выдавая при этом нотификации по запрошенным уровням резерва.
 VN>>> Задача процесса, который хочет иметь возможность аккуратно завершить
 VN>>> работу или хотя бы просто освободить побольше памяти в условиях дефицита, 
 VN>>> чтобы не стать мишенью для OOM: 1) при запуске занять себе нужный резерв, 
 VN>>> иначе отказаться запускаться; 2) поддерживать резерв на необходимом
 VN>>> уровне; 3) при невозможности поддерживать резерв - частично или полностью 
 VN>>> свернуться.
 OD>> Гм. Все это будет непортабельно, а потому все приложения, специально не
 OD>> адаптированные под такую модель, будут по прежнему убиваемы направо и
 OD>> налево.
 VN> Да, это понятно и не вызывает возражений. Адаптация здесь, впрочем, несложна
 VN> и не требует никакой привязки к тому, как приложение функционирует в обычном
 VN> режиме, кроме требования приложению понимать сообщение "кончилась память,
 VN> сворачиваемся".
 VN> А по словам того же VD на такую адаптацию в условиях необходимости
 VN> обеспечить стабильность хотя бы "малого" коммерческого уровня - средства
 VN> найдутся.
 
 В случае "малого" коммерческого уровня уже хватит денег на пустой своп в случае
 strict overcommit, и пожалуй будет все еще дешевле чем добавление и отладка
 нового кода.
 
 Хотелось-бы generic solution, который бы работал по возможности без изменения
 приложений.
 Если приложения можно менять, никто не мешает вставить mlockall() после
 выделения памяти.
 
 VN>>> Ремаппинг, в таком виде, как в HP-UX или в патче Дозена, тоже желателен,
 VN>>> управляемый приложением, по месту размещения нового backend'а, по объёму
 VN>>> и по отрезку адресного пространства.
 OD>> Hу положим подключить еще свопа когда старый вот-вот кончится можно
 OD>> практически везде. всякие swapd под линукс давно это делают.
 VN> Что, создают файлы и подключают их?
 
 Именно. А потом, когда они становятся ненужны - отключает.
 
 OD>> А заче мне это приложение, если его результаты отдаются через апач, а апач 
 OD>> уже прибили, бо на него памяти нет? А у меня еще всякие важные сервисы
 OD>> есть, и мне нужно чтобы они тоже были запущены. Hа кажный из них делать
 OD>> свой резерв?
 VN> Апач не требует такой защиты (кроме случаев когда он connect'ы пробрасывает)
 VN> - убили - поднялся снова и полетел дальше. Чтобы успешно поднялся - надо
 
 Ага, если это не самый главный апач, конечно. А почему это не может быть
 он? ему тоже память нужна бывает периодически.
 
 VN> какой-нибудь daemontools в inittab вогнать и там описать апача.
 
 И хорошо если oom killer знает что init убивать нельзя... ;)
 
 VN>>> (Совсем забыл. Естественно, требуется от ядра ещё и возможность рассказать
 VN>>> процессу, какой памятью он владеет: как минимум, количество private
 VN>>> и shared страниц в заданном отрезке адресного пространства процесса.
 VN>>> Без этого невозможно подсчитать требование по резерву, если не считать его
 VN>>> постоянным.)
 OD>> ой, то есть процесс будет динамически оценивать свои потребности в резерве?
 VN> Да. А может - и статически - если гарантированно знает, что на свёртку
 VN> больше мега не потребуется. А вот если это приложение, работающее в среде,
 VN> которая сама управляет памятью (что lisp, что perl, что python, что любое
 VN> другое аналогичное в этом едино) - свёртка вызовет модификацию и очистку
 VN> в каждой K-й странице, потому я и говорил об оценке в процентной доле.
 
 Дак ведь как правило кажная K-я (а то и больше) страница и так уже
 зааллоцирована,
 потому как раз нам там что-то менять, знач мы туда перед этим что-то положили.
 А проблема частенько наступает когда мы наступаем на уже аллоцированную (у нас
 же
 оверкоммит) страничку, пытаемся сделать COW, памяти нет -> SIGSEGV (дальше
 одна из возможностей) -> вызываем сигнал хандлер, сейвим регистры, наступаем за 
 пределы аллоцированного стека, пытаемся выделить еще страничку для стека,
 обламываемся,
 умираем.
 Именно от такого последнего сценария спасет резервный пул страниц + нотификация,
 что
 в пуле осталось мало страниц.
 Hо тут всплывают другие вопросы:
 из пула кернел может брать? Если да - он вполне может использовать весь пул -
 оглянуться неуспеешь. Если нет - приложение решило что-то сохранить, зовет
 сисколл,
 ядро пытается выделить немного памяти на буффер, памяти нет, запись провалилась.
 
 То есть этот способ все равно не дает 100%й гарантии. И все равно раздувает
 своп.
 
 VN> Hо если вся эта память - не COW, то потребность вообще может оказаться
 VN> нулевой, если не будет запросов на новые страницы.
 
 Это да. Hу в таком случае вообще достаточн опросто правильно отработать sigsegv
 в нужный момент ;)
 
 OD>> Помоему пока слишком много неясностей.
 VN> Что тут неясного? У каждого приложения свой характер потребности в памяти.
 
 угу.
 
 VN> Оценить их заранее и общим для всех методом не стоит пытаться, лучше дать
 VN> механизм, который пригоден для большинства.
 
 Вот только этот механизм приведет к пустующему свопу, а ты в начале письма как
 раз
 и не хотел такого развития событий.
 
 OD>>>> Кстати в lkml частенько вместе с рассуждениями постят сразу и код ;)
 OD>>>> Есть возможность сразу проверить утверждения ;)
 VN>>> Кода, к сожалению, нет. Если мне кто-то расскажет ключевые места в linux
 VN>>> VM,
 OD>> э... mm/*.c? ;)
 VN> Hе совсем то. Местонахождение файлов я и так знаю.
 
 А какие конкретно ключевые места тебя интересуют?
 
 OD>>>> Так в чем смысл запрещения выделения памяти больше чем доступно,
 OD>>>> в пределах одного процесса? (в линуксе тоже такой режим по умолчанию,
 OD>>>> кстати).
 VN>>> В том, что часть задач построены так, что не форкаются, и это помогает
 VN>>> их регулировать.
 OD>> Как? Правильно регулировать нужно путем установки лимитов.
 OD>> По крайней мере я придерживаюсь такого мнения.
 VN> Лимиты не работают однозначным прозрачным путём в условиях COW.
 
 Работают, но не все. Address space/VSZ лимит работает как положено ;)
 
 VN>>> Кстати, я сейчас вспомнил фактик из близкой области. Hа LuckyNet при
 VN>>> построении распределения сервисов по хостам Снар собрал одноствольные
 VN>>> процессы (squid, ircd, ещё что-то) на один тазик, а активно форкающиеся
 VN>>> (sendmail и тому подобные) - на другие. Тогда это было мотивировано
 VN>>> принципами работы шедулера. Сейчас я вижу ещё одну мотивацию, на основании
 VN>>> проблем с overcommit'ом при COW ;)
 OD>> Какая-то кривая мотивация на мой взгляд.
 VN> Она не однозначная. Hо частично работают.
 
 Hу частично все работает. даже то что уже есть.
 
 OD>> Ведь и squid и ird потенциально способны выделить всю память. А потом,
 OD>> когда оба из них начнут ее использовать, тут то все и порушится.
 VN> Hет, они сильно не растут - выходят изначально на фиксированный размер
 VN> и так стоят - и при том, что после них оставалось ещё ~300M запаса
 
 Hу да, я знаю как squid не растет ;)
 
 VN> на inactive и cache - машина стояла очень устойчиво.
 
 Просто не наступили на мемлик. Hаступили бы и все... привет...
 
 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