|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 26 Feb 2003 17:07:59
To : Oleg Drokin
Subject : Re: Swap
--------------------------------------------------------------------------------
>>> Oleg Drokin wrote:
OD>>> So what is strict VM overcommit? We introduce new overcommit policies
OD>>> that attempt to never succeed an allocation that can not be fulfilled by
OD>>> the backing store and consequently never OOM. This is achieved through
OD>>> strict accounting of the committed address space and a policy to
OD>>> allow/refuse allocations based on that accounting.
VN>> Мне это кажется чрезмерным. Hормальный подход должен учитывать, что shared
VN>> страницы - нормальная ситуация и делать их строго раздельными - неэкономно.
OD> Если под shared иметь ввиду MAP_SHARED, то у них уже есть backing space.
COW.
OD> Если cow-мапинги, то несмотря на нормальность ситуации, нельзя сказать
OD> достоверно, будет ли вот-эта конкретная страница в будущем разделена на две
OD> по факту записи или нет.
Hельзя. И реально большинство всё-таки не делятся.
VN>> Ладно, я перескажу, чего мы там надумали. Изначально Vladimir Dozen
VN>> поднял тему вот в каком виде. У него крутится очень толстый сервер
VN>> на дофига долгоживущих соединений, каждое из которых требует сложную
VN>> и ресурсоёмкую отработку (что-то вроде CORBA proxy).
VN>> Хотелось сделать это на linux, но если кончается память, то сшибается
VN>> задача целиком, и ей не дают даже пискнуть. "Писк" - аккуратная свёртка
VN>> работы -
OD> Обсуждалось посылание задаче sigterm, и если она некоторое время не
OD> отвечает, то sigkill. Естественно когда памяти нет - это все равно толком ни
OD> к чему хорошему не приводит.
Вот в том и дело, что памяти уже нет, а на операции свёртки требуется
ещё кусочек.
VN>> сама по себе требует обычно ещё выделить кусочек памяти, которой уже нет.
OD> угу.
VN>> (Это типичная ситуация, когда требуется сделать какие-то действия при
VN>> завершении и когда они обычно сводятся к генерации исключения, вызывающего
VN>> размотку стека.)
VN>> Оформились два подхода - первый имени меня, потенциально навороченный и
VN>> близкий к идеалу, но совершенно непонятно как реализовывать (я попытался
VN>> покопаться в VM'ах и не дошёл ни до чего практического), второй имени VD,
VN>> сделанный в виде работающего патча для FreeBSD VM и повторяющий
VN>> функциональность реализации в HP-UX и некоторых других коммерческих
VN>> юниксах. Сначала о втором. При нехватке памяти делается ремаппинг памяти
VN>> процесса, имеющей своп в качестве backend'а, на файл, то есть содержимое
VN>> отрезка адресного пространства сбрасывается в файл и устанавливается
VN>> отображение этого файла на этот отрезок. Где этот файл - применяется
VN>> общесистемная
OD> Хм, чем это отличается от подхода просто иметь некий резерв памяти,
OD> доступный только при OOM и только определенным uid? (такой подход
OD> закритиковали в lkml, потому как он все равно толком работать не будет.)
Тем, что это вовне свопа. Если раздуть своп, он большую часть времени будет
просто пустовать. Если сделать выброс в /tmp, то получим разделение места
между программами, жрущими память, и программами, жрущими винт.
Если нет одовременно пожирания и теми и теми, получаем удобное разделение
во времени, как и при обычном использовании /tmp.
Если есть, то можно раздуть своп, и если даже такой раздутый своп
исчерпается - всё равно будет ещё кусочек спецрезерва.
VN>> настройка, но в общем в каком-то из tmp. Понятно, что это аварийное
VN>> средство, и что место на этом tmp тоже может кончиться.
OD> Угу. Если мы имеем случай неконтролируемого мемори лика в процессе, то
OD> допустим мы отобразили часть процесса в файл. И что? Пусть дальше растет
OD> пока место есть?
Да. А чтобы не мешал остальным, если не положено, надо нормально реализовать
лимиты. Per-uid, per-tree и прочие. И квоты на разделе на диске.
OD> Может ему все-же сигнал послать? А если он не отрабатывает сигнал?
Если он не отрабатывает и память кончается - он получает фигу в
соответствующем ситуации исполнении.
OD> А всей остальной системе в это время что делать? Ей-то тоже память нужна...
Эти методы не исключают стандартый OOM и не противоречат ему.
Если память уже кончилась, поздно пить боржоми - надо стрелять.
А вот чтобы была возможность не довести до стрельбы - и делаются такие
подходы.
OD> (это так сказать краткий перечень вопросов из lkml которые сразу задаются
OD> сторонникам подхода резервировать часть памяти).
То есть там собралась компания, которая "опускает" всех каверзными вопросами
и ничего при этом не делает?
VN>> Теперь первый, мой. Декларируется, что процесс может иметь заранее
VN>> закоммиченный резерв места в VM. (Если наличие этого резерва жизненно важно
VN>> для процесса, то успешное его выделение должно быть частью необходимой
VN>> частью инициализации работы процесса.)
OD> mlock() ?
Оно не должно отображаться.
VN>> Этот резерв не отображается в адресное пространство процесса. Ядро
VN>> поддерживает регулирование размера этого резерва, с учётом лимитов,
VN>> получение размера, установку нотификаций на трату этого резерва (на 2-3
VN>> заданных уровня, снижение до которых вызовет нотификацию) и генерацию
VN>> сигнала (или иного оповещения) этой нотификации. По коммитам страниц, для
VN>> которых был при их аллокации задан lazy commit, и по созданию персональной
VN>> копии COW страницы, ядро пытается получить сначала свободную страницу из
VN>> VM, а если общее исчерпание или лимиты этому мешают, начинает тратить из
VN>> резерва процесса,
OD> А до того как оно начнет ее тратить, у нас просто есть кусок никем не
OD> используемой памяти "на всякий случай"?
Именно.
VN>> выдавая при этом нотификации по запрошенным уровням резерва.
VN>> Задача процесса, который хочет иметь возможность аккуратно завершить работу
VN>> или хотя бы просто освободить побольше памяти в условиях дефицита, чтобы
VN>> не стать мишенью для OOM: 1) при запуске занять себе нужный резерв, иначе
VN>> отказаться запускаться; 2) поддерживать резерв на необходимом уровне;
VN>> 3) при невозможности поддерживать резерв - частично или полностью
VN>> свернуться.
OD> Гм. Все это будет непортабельно, а потому все приложения, специально не
OD> адаптированные под такую модель, будут по прежнему убиваемы направо и
OD> налево.
Да, это понятно и не вызывает возражений. Адаптация здесь, впрочем, несложна
и не требует никакой привязки к тому, как приложение функционирует в обычном
режиме, кроме требования приложению понимать сообщение "кончилась память,
сворачиваемся".
А по словам того же VD на такую адаптацию в условиях необходимости обеспечить
стабильность хотя бы "малого" коммерческого уровня - средства найдутся.
OD> И значит в обычных условиях без специально-обученных приложений OOM (который
OD> кстати все равно будет, только раньше. У этого-то процесса резерв, но
OD> другие-то туда руки совать не могут, потому другие колбасятся вообще без
OD> памяти, тогда как у этого процесса еще есть запасы).
Да, именно так.
VN>> Ремаппинг, в таком виде, как в HP-UX или в патче Дозена, тоже желателен,
VN>> управляемый приложением, по месту размещения нового backend'а, по объёму
VN>> и по отрезку адресного пространства.
OD> Hу положим подключить еще свопа когда старый вот-вот кончится можно
OD> практически везде. всякие swapd под линукс давно это делают.
Что, создают файлы и подключают их?
VN>> Возьмём ту ситуацию, где у тебя 12 гиг. Предположим, что половина из них -
VN>> затрачена на некоторое толстое и важное приложение, имеющее к тому же
VN>> несколько процессов с копиями данных. Hормальный резерв, по первичной
VN>> прикидке (не проверял, только рассуждения на основании хилых данных) - 10%.
VN>> Тогда создание первичного резерва потребует 600M виртуальной памяти
VN>> (считай, свопа). Как по мне, совсем неплохо.
OD> При этом я защищаю только одно это приложение, все остальные (а мне они тоже
OD> нужны), будут прибиты при OOM (пусть даже вызвынным тем критическим отлстым
OD> приложением, но у него-то еще нет OOM).
Да.
OD> А заче мне это приложение, если его результаты отдаются через апач, а апач
OD> уже прибили, бо на него памяти нет? А у меня еще всякие важные сервисы есть,
OD> и мне нужно чтобы они тоже были запущены. Hа кажный из них делать свой
OD> резерв?
Апач не требует такой защиты (кроме случаев когда он connect'ы пробрасывает) -
убили - поднялся снова и полетел дальше. Чтобы успешно поднялся - надо
какой-нибудь daemontools в inittab вогнать и там описать апача.
VN>> (Совсем забыл. Естественно, требуется от ядра ещё и возможность рассказать
VN>> процессу, какой памятью он владеет: как минимум, количество private
VN>> и shared страниц в заданном отрезке адресного пространства процесса.
VN>> Без этого невозможно подсчитать требование по резерву, если не считать его
VN>> постоянным.)
OD> ой, то есть процесс будет динамически оценивать свои потребности в резерве?
Да. А может - и статически - если гарантированно знает, что на свёртку
больше мега не потребуется. А вот если это приложение, работающее в среде,
которая сама управляет памятью (что lisp, что perl, что python, что любое
другое аналогичное в этом едино) - свёртка вызовет модификацию и очистку
в каждой K-й странице, потому я и говорил об оценке в процентной доле.
Hо если вся эта память - не COW, то потребность вообще может оказаться
нулевой, если не будет запросов на новые страницы.
OD> Помоему пока слишком много неясностей.
Что тут неясного? У каждого приложения свой характер потребности в памяти.
Оценить их заранее и общим для всех методом не стоит пытаться, лучше дать
механизм, который пригоден для большинства.
OD>>> Кстати в lkml частенько вместе с рассуждениями постят сразу и код ;)
OD>>> Есть возможность сразу проверить утверждения ;)
VN>> Кода, к сожалению, нет. Если мне кто-то расскажет ключевые места в linux
VN>> VM,
OD> э... mm/*.c? ;)
Hе совсем то. Местонахождение файлов я и так знаю.
VN>> а заодно даст URL на методы отладки ядра, я могу подумать ;)
OD> http://user-mode-linux.sf.net, там есть usermodelinux.
OD> Его можно запускать под gdb, что есть очень удобно (особенно
OD> если патчится VM или еще что-то такого плана, не связанного с
OD> железками. Впрочем с появлением патча для VPCI уже можно и
OD> драйвера для PCI девайсов отлаживать).
OD> Правда под FreeBSD оно не работает, слишком уж привязано к glibc.
OD> А есть еще http://www.kernelnewbies.org со ссылками на разную документацию
OD> по отладке и написанию кернелного кода.
Хм, посмотрю.
OD>>> Так ведь эта, какая разница что я маллоком не могу выделить памяти больше
OD>>> чем есть? Все равно я запущу два таких приложения и памяти нехватит. И все
OD>>> равно при наступании в выделенную область я получу sigsegv (или там sigbus
OD>>> во фре?).
тут тоже SIGSEGV.
OD>>> Так в чем смысл запрещения выделения памяти больше чем доступно,
OD>>> в пределах одного процесса? (в линуксе тоже такой режим по умолчанию,
OD>>> кстати).
VN>> В том, что часть задач построены так, что не форкаются, и это помогает
VN>> их регулировать.
OD> Как? Правильно регулировать нужно путем установки лимитов.
OD> По крайней мере я придерживаюсь такого мнения.
Лимиты не работают однозначным прозрачным путём в условиях COW.
VN>> Кстати, я сейчас вспомнил фактик из близкой области. Hа LuckyNet при
VN>> построении распределения сервисов по хостам Снар собрал одноствольные
VN>> процессы (squid, ircd, ещё что-то) на один тазик, а активно форкающиеся
VN>> (sendmail и тому подобные) - на другие. Тогда это было мотивировано
VN>> принципами работы шедулера. Сейчас я вижу ещё одну мотивацию, на основании
VN>> проблем с overcommit'ом при COW ;)
OD> Какая-то кривая мотивация на мой взгляд.
Она не однозначная. Hо частично работают.
OD> Ведь и squid и ird потенциально способны выделить всю память. А потом, когда
OD> оба из них начнут ее использовать, тут то все и порушится.
Hет, они сильно не растут - выходят изначально на фиксированный размер
и так стоят - и при том, что после них оставалось ещё ~300M запаса
на inactive и cache - машина стояла очень устойчиво.
-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 |
|
|
