|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 26 Feb 2003 11:44:37
To : Oleg Drokin
Subject : Re: Swap
--------------------------------------------------------------------------------
>>> Oleg Drokin wrote:
OD>>> А вдруг процесс в нее запишет? Значит прийдется делать COW. Значит нужно
OD>>> чтоб было куда. А если этого нет, то тогда мы получаем включенный
OD>>> overcommit со всеми его прелестями в большей или меньшей степени.
VN>> Hесмотря на то, что по сути это вариант overcommit'а, его не принято
VN>> так называть.
OD> Где как.
Во фряшных кругах, похоже, именно так.
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.
Мне это кажется чрезмерным. Hормальный подход должен учитывать, что shared
страницы - нормальная ситуация и делать их строго раздельными - неэкономно.
OD>>> Да в lkml регулярно такие обсуждения.
VN>> Вы в состоянии читать lkml? У Вас есть на это время?
OD> Мне платят деньги за чтение lkml (ну и не только за это, само собой).
Всё, вопросов нет. ;)
OD> Конечно, я читаю в основном то что мне покажется интересным и то что мне
OD> нужно в плане работы. (ну плюс еще багрепорты).
VN>> Если Вы видите смысл в рассказанном там, перескажите.
OD> Мнений много, и каждый тянет одеяло на себя. (впрочем почти никто не
OD> предлагает совсем-совсем отключать оверкоммит в общем смысле этого слова).
OD> А все пересказывать долго. К тому же обычно такие обсуждения длинные и
OD> скучные. И все равно они почти всегда скатываются к тому, как заимпрувить
OD> oom_killer ;)
Ладно, я перескажу, чего мы там надумали. Изначально Vladimir Dozen
поднял тему вот в каком виде. У него крутится очень толстый сервер
на дофига долгоживущих соединений, каждое из которых требует сложную
и ресурсоёмкую отработку (что-то вроде CORBA proxy).
Хотелось сделать это на linux, но если кончается память, то сшибается задача
целиком, и ей не дают даже пискнуть. "Писк" - аккуратная свёртка работы -
сама по себе требует обычно ещё выделить кусочек памяти, которой уже нет.
(Это типичная ситуация, когда требуется сделать какие-то действия при
завершении и когда они обычно сводятся к генерации исключения, вызывающего
размотку стека.)
Оформились два подхода - первый имени меня, потенциально навороченный и
близкий к идеалу, но совершенно непонятно как реализовывать (я попытался
покопаться в VM'ах и не дошёл ни до чего практического), второй имени VD,
сделанный в виде работающего патча для FreeBSD VM и повторяющий
функциональность реализации в HP-UX и некоторых других коммерческих юниксах.
Сначала о втором. При нехватке памяти делается ремаппинг памяти процесса,
имеющей своп в качестве backend'а, на файл, то есть содержимое отрезка
адресного пространства сбрасывается в файл и устанавливается отображение
этого файла на этот отрезок. Где этот файл - применяется общесистемная
настройка, но в общем в каком-то из tmp. Понятно, что это аварийное средство,
и что место на этом tmp тоже может кончиться.
Теперь первый, мой. Декларируется, что процесс может иметь заранее
закоммиченный резерв места в VM. (Если наличие этого резерва жизненно важно
для процесса, то успешное его выделение должно быть частью необходимой
частью инициализации работы процесса.)
Этот резерв не отображается в адресное пространство процесса. Ядро
поддерживает регулирование размера этого резерва, с учётом лимитов, получение
размера, установку нотификаций на трату этого резерва (на 2-3 заданных уровня,
снижение до которых вызовет нотификацию) и генерацию сигнала (или иного
оповещения) этой нотификации. По коммитам страниц, для которых был при
их аллокации задан lazy commit, и по созданию персональной копии COW страницы,
ядро пытается получить сначала свободную страницу из VM, а если общее
исчерпание или лимиты этому мешают, начинает тратить из резерва процесса,
выдавая при этом нотификации по запрошенным уровням резерва.
Задача процесса, который хочет иметь возможность аккуратно завершить работу
или хотя бы просто освободить побольше памяти в условиях дефицита, чтобы
не стать мишенью для OOM: 1) при запуске занять себе нужный резерв, иначе
отказаться запускаться; 2) поддерживать резерв на необходимом уровне;
3) при невозможности поддерживать резерв - частично или полностью свернуться.
Ремаппинг, в таком виде, как в HP-UX или в патче Дозена, тоже желателен,
управляемый приложением, по месту размещения нового backend'а, по объёму
и по отрезку адресного пространства.
Возьмём ту ситуацию, где у тебя 12 гиг. Предположим, что половина из них -
затрачена на некоторое толстое и важное приложение, имеющее к тому же
несколько процессов с копиями данных. Hормальный резерв, по первичной
прикидке (не проверял, только рассуждения на основании хилых данных) - 10%.
Тогда создание первичного резерва потребует 600M виртуальной памяти (считай,
свопа). Как по мне, совсем неплохо.
(Совсем забыл. Естественно, требуется от ядра ещё и возможность рассказать
процессу, какой памятью он владеет: как минимум, количество private
и shared страниц в заданном отрезке адресного пространства процесса.
Без этого невозможно подсчитать требование по резерву, если не считать его
постоянным.)
OD>>> Только полностью дизаблить оверкоммит и иметь гигабайты свопа, который
OD>>> никогда не будет использоваться, но при этом если эжтого свопа не иметь,
OD>>> то ни на что не хватит памяти мне как-то неинтересно.
VN>> Зря Вы таки не прочитали тред в ru.unix.prog. Речь шла о том, что можно
VN>> получить необходимую надёжность без мер по заведению гигабайт
VN>> неиспользуемого свопа (хотя это и требует не совсем простых модификаций
VN>> VM). Могу пересказать здесь, если не доберётесь.
OD> Да, было бы любопытно.
Hу вот рассказал.
OD> Кстати в lkml частенько вместе с рассуждениями постят сразу и код ;)
OD> Есть возможность сразу проверить утверждения ;)
Кода, к сожалению, нет. Если мне кто-то расскажет ключевые места в linux VM,
а заодно даст URL на методы отладки ядра, я могу подумать ;)
OD>>> Что значит "если"? У нас memory overcommit или разрешен или запрещен.
OD>>> То есть сейчас он разрешен и все хорошо, но если я его вдруг разрешу,
OD>>> то мне прийдется добавить еще 12 гигабайт свопа просто так. (и при этом
OD>>> я знаю что мои процессы не захотят записать свои данные).
VN>> Hу вот FreeBSD'шники думают иначе - что явный overcommit по выделению
VN>> памяти malloc'ом не надо разрешать, а он же за счёт держания одной
VN>> копии shared страниц - неизбежное зло. И я с ними вполне согласен.
OD> Так ведь эта, какая разница что я маллоком не могу выделить памяти больше
OD> чем есть? Все равно я запущу два таких приложения и памяти нехватит. И все
OD> равно при наступании в выделенную область я получу sigsegv (или там
OD> sigbus во фре?). Так в чем смысл запрещения выделения памяти больше чем
OD> доступно, в пределах одного процесса? (в линуксе тоже такой режим по
OD> умолчанию, кстати).
В том, что часть задач построены так, что не форкаются, и это помогает
их регулировать.
Кстати, я сейчас вспомнил фактик из близкой области. Hа LuckyNet при
построении распределения сервисов по хостам Снар собрал одноствольные
процессы (squid, ircd, ещё что-то) на один тазик, а активно форкающиеся
(sendmail и тому подобные) - на другие. Тогда это было мотивировано
принципами работы шедулера. Сейчас я вижу ещё одну мотивацию, на основании
проблем с overcommit'ом при COW ;)
-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 |
|
|
