|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Drokin 2:5020/400 26 Feb 2003 13:07:33
To : Valentin Nechayev
Subject : Re: Swap
--------------------------------------------------------------------------------
Hello!
Valentin Nechayev <netch@segfault.kiev.ua> wrote:
OD>>>> А вдруг процесс в нее запишет? Значит прийдется делать COW. Значит нужно
OD>>>> чтоб было куда. А если этого нет, то тогда мы получаем включенный
OD>>>> overcommit со всеми его прелестями в большей или меньшей степени.
VN>>> Hесмотря на то, что по сути это вариант overcommit'а, его не принято
VN>>> так называть.
OD>> Где как.
VN> Во фряшных кругах, похоже, именно так.
;)
OD>> Кстати такой режим (совсем запрезенные overcommit) для Linux есть.
OD>> В виде патча ;)
OD>> Robert Love <rml@tech9.net>:
OD>> The attached patch implements strict VM overcommit on top of the rmap VM.
OD>> ...
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> страницы - нормальная ситуация и делать их строго раздельными - неэкономно.
Если под shared иметь ввиду MAP_SHARED, то у них уже есть backing space.
Если cow-мапинги, то несмотря на нормальность ситуации, нельзя сказать
достоверно,
будет ли вот-эта конкретная страница в будущем разделена на две по факту записи
или нет.
Да, я согласен что неэкономно (есть кстати оси в которых по другому нельзя,
вроде даже старая солярка/санос).
В Linux это реализовали по запросу всяких enterprise и embedded people, которым
нужна абсолютная предсказуемость. И которые не могут себе позволить всякие
oom_killer'ы ;)
OD>> Конечно, я читаю в основном то что мне покажется интересным и то что мне
OD>> нужно в плане работы. (ну плюс еще багрепорты).
VN>>> Если Вы видите смысл в рассказанном там, перескажите.
OD>> Мнений много, и каждый тянет одеяло на себя. (впрочем почти никто не
OD>> предлагает совсем-совсем отключать оверкоммит в общем смысле этого слова).
OD>> А все пересказывать долго. К тому же обычно такие обсуждения длинные и
OD>> скучные. И все равно они почти всегда скатываются к тому, как заимпрувить
OD>> oom_killer ;)
VN> Ладно, я перескажу, чего мы там надумали. Изначально Vladimir Dozen
VN> поднял тему вот в каком виде. У него крутится очень толстый сервер
VN> на дофига долгоживущих соединений, каждое из которых требует сложную
VN> и ресурсоёмкую отработку (что-то вроде CORBA proxy).
VN> Хотелось сделать это на linux, но если кончается память, то сшибается задача
VN> целиком, и ей не дают даже пискнуть. "Писк" - аккуратная свёртка работы -
Обсуждалось посылание задаче sigterm, и если она некоторое время не отвечает,
то sigkill. Естественно когда памяти нет - это все равно толком ни к чему
хорошему не приводит.
VN> сама по себе требует обычно ещё выделить кусочек памяти, которой уже нет.
угу.
VN> (Это типичная ситуация, когда требуется сделать какие-то действия при
VN> завершении и когда они обычно сводятся к генерации исключения, вызывающего
VN> размотку стека.)
VN> Оформились два подхода - первый имени меня, потенциально навороченный и
VN> близкий к идеалу, но совершенно непонятно как реализовывать (я попытался
VN> покопаться в VM'ах и не дошёл ни до чего практического), второй имени VD,
VN> сделанный в виде работающего патча для FreeBSD VM и повторяющий
VN> функциональность реализации в HP-UX и некоторых других коммерческих юниксах.
VN> Сначала о втором. При нехватке памяти делается ремаппинг памяти процесса,
VN> имеющей своп в качестве backend'а, на файл, то есть содержимое отрезка
VN> адресного пространства сбрасывается в файл и устанавливается отображение
VN> этого файла на этот отрезок. Где этот файл - применяется общесистемная
Хм, чем это отличается от подхода просто иметь некий резерв памяти, доступный
только при OOM и только определенным uid? (такой подход закритиковали в
lkml, потому как он все равно толком работать не будет.)
VN> настройка, но в общем в каком-то из tmp. Понятно, что это аварийное
VN> средство, и что место на этом tmp тоже может кончиться.
Угу. Если мы имеем случай неконтролируемого мемори лика в процессе, то допустим
мы
отобразили часть процесса в файл. И что? Пусть дальше растет пока место есть?
Может ему все-же сигнал послать? А если он не отрабатывает сигнал?
А всей остальной системе в это время что делать? Ей-то тоже память нужна...
(это так сказать краткий перечень вопросов из lkml которые сразу задаются
сторонникам подхода резервировать часть памяти).
VN> Теперь первый, мой. Декларируется, что процесс может иметь заранее
VN> закоммиченный резерв места в VM. (Если наличие этого резерва жизненно важно
VN> для процесса, то успешное его выделение должно быть частью необходимой
VN> частью инициализации работы процесса.)
mlock() ?
VN> Этот резерв не отображается в адресное пространство процесса. Ядро
VN> поддерживает регулирование размера этого резерва, с учётом лимитов,
VN> получение размера, установку нотификаций на трату этого резерва (на 2-3
VN> заданных уровня, снижение до которых вызовет нотификацию) и генерацию
VN> сигнала (или иного оповещения) этой нотификации. По коммитам страниц, для
VN> которых был при их аллокации задан lazy commit, и по созданию персональной
VN> копии COW страницы, ядро пытается получить сначала свободную страницу из VM,
VN> а если общее исчерпание или лимиты этому мешают, начинает тратить из резерва
VN> процесса,
А до того как оно начнет ее тратить, у нас просто есть кусок никем не
используемой памяти
"на всякий случай"?
VN> выдавая при этом нотификации по запрошенным уровням резерва.
VN> Задача процесса, который хочет иметь возможность аккуратно завершить работу
VN> или хотя бы просто освободить побольше памяти в условиях дефицита, чтобы
VN> не стать мишенью для OOM: 1) при запуске занять себе нужный резерв, иначе
VN> отказаться запускаться; 2) поддерживать резерв на необходимом уровне;
VN> 3) при невозможности поддерживать резерв - частично или полностью
VN> свернуться.
Гм. Все это будет непортабельно, а потому все приложения, специально не
адаптированные
под такую модель, будут по прежнему убиваемы направо и налево.
И значит в обычных условиях без специально-обученных приложений OOM (который
кстати все
равно будет, только раньше. У этого-то процесса резерв, но другие-то туда руки
совать
не могут, потому другие колбасятся вообще без памяти, тогда как у этого процесса
еще есть запасы).
VN> Ремаппинг, в таком виде, как в HP-UX или в патче Дозена, тоже желателен,
VN> управляемый приложением, по месту размещения нового backend'а, по объёму
VN> и по отрезку адресного пространства.
Hу положим подключить еще свопа когда старый вот-вот кончится можно практически
везде. всякие swapd под линукс давно это делают.
VN> Возьмём ту ситуацию, где у тебя 12 гиг. Предположим, что половина из них -
VN> затрачена на некоторое толстое и важное приложение, имеющее к тому же
VN> несколько процессов с копиями данных. Hормальный резерв, по первичной
VN> прикидке (не проверял, только рассуждения на основании хилых данных) - 10%.
VN> Тогда создание первичного резерва потребует 600M виртуальной памяти (считай,
VN> свопа). Как по мне, совсем неплохо.
При этом я защищаю только одно это приложение, все остальные (а мне они тоже
нужны),
будут прибиты при OOM (пусть даже вызвынным тем критическим отлстым приложением,
но у него-то еще нет OOM).
А заче мне это приложение, если его результаты отдаются через апач, а апач уже
прибили,
бо на него памяти нет? А у меня еще всякие важные сервисы есть, и мне нужно
чтобы
они тоже были запущены. Hа кажный из них делать свой резерв?
VN> (Совсем забыл. Естественно, требуется от ядра ещё и возможность рассказать
VN> процессу, какой памятью он владеет: как минимум, количество private
VN> и shared страниц в заданном отрезке адресного пространства процесса.
VN> Без этого невозможно подсчитать требование по резерву, если не считать его
VN> постоянным.)
ой, то есть процесс будет динамически оценивать свои потребности в резерве?
Помоему пока слишком много неясностей.
OD>> Кстати в lkml частенько вместе с рассуждениями постят сразу и код ;)
OD>> Есть возможность сразу проверить утверждения ;)
VN> Кода, к сожалению, нет. Если мне кто-то расскажет ключевые места в linux VM,
э... mm/*.c? ;)
VN> а заодно даст URL на методы отладки ядра, я могу подумать ;)
http://user-mode-linux.sf.net, там есть usermodelinux.
Его можно запускать под gdb, что есть очень удобно (особенно
если патчится VM или еще что-то такого плана, не связанного с
железками. Впрочем с появлением патча для VPCI уже можно и
драйвера для PCI девайсов отлаживать).
Правда под FreeBSD оно не работает, слишком уж привязано к glibc.
А есть еще http://www.kernelnewbies.org со ссылками на разную документацию
по отладке и написанию кернелного кода.
OD>> Так ведь эта, какая разница что я маллоком не могу выделить памяти больше
OD>> чем есть? Все равно я запущу два таких приложения и памяти нехватит. И все
OD>> равно при наступании в выделенную область я получу sigsegv (или там sigbus
OD>> во фре?). Так в чем смысл запрещения выделения памяти больше чем доступно,
OD>> в пределах одного процесса? (в линуксе тоже такой режим по
OD>> умолчанию, кстати).
VN> В том, что часть задач построены так, что не форкаются, и это помогает
VN> их регулировать.
Как? Правильно регулировать нужно путем установки лимитов.
По крайней мере я придерживаюсь такого мнения.
VN> Кстати, я сейчас вспомнил фактик из близкой области. Hа LuckyNet при
VN> построении распределения сервисов по хостам Снар собрал одноствольные
VN> процессы (squid, ircd, ещё что-то) на один тазик, а активно форкающиеся
VN> (sendmail и тому подобные) - на другие. Тогда это было мотивировано
VN> принципами работы шедулера. Сейчас я вижу ещё одну мотивацию, на основании
VN> проблем с overcommit'ом при COW ;)
Какая-то кривая мотивация на мой взгляд.
Ведь и squid и ird потенциально способны выделить всю память. А потом, когда оба
из
них начнут ее использовать, тут то все и порушится.
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 |
|
|
