On Sat, Jul 08, 2006 at 01:51:29PM +0300, Dmitry Pryanishnikov wrote:
Привет!
On Sat, 8 Jul 2006, Paul Arakelyan wrote:
Эт всё хорошо, но "без спросу" отрывать диск с открытыми файлами - это как-то неправильно. Короче, "потрясающий менеджмент ресурсов".
Менеджмент системных, критичных ресурсов (своп - один из них) всегда был заботой системного администратора. И у него всегда было для этого средство в виде process resource limits, login.conf(5). Если в Вашей системе этот механизм не предотвратил исчерпания свопа (за счет ограничения maxproc, datasize, stacksize, ...), это говорит о том, что Вы его просто не настроили адекватно.
Адекватно при разделении ресурсов между кучей всего настроить что-либо можно только "порезав" ресурсы так, чтоб друг-другу не мешали. То есть потенциально выбросить часть мощностей системы "на ветер". Приходится выбирать.
Стоп - я "отожрал" заданный кусок памяти - и "дальше - хоть потоп", диск же не наращивается в объёме - зачем тогда "неистощаемость ресурсов"?
Я знал, я знал ;) Мне кажется, Вы неверно представляете себе динамику "отжирания" свопа. Он выделяется не в момент запуска mdmfs, а по мере заполнения полученного диска. Попробуйте (если на машине достаточно свопа) издать, например
mdmfs -s 512m md /mnt dd if=/dev/zero of=/mnt/aaa bs=1m У меня туда 1 раз "заливается" несколько файлов - "и всё". Далее - только читается. В принципе - мне нужно гарантированное торчание этого MFS в памяти...
и понаблюдайте с другой консоли за тем, как swapinfo показывает реальное использование свопа Вашим диском. Так что "отжор" здесь производится динамически, при работе с диском.
Своп, к сожалению, более критичный ресурс, чем свободное место на файловых системах. Если в Вашей системе он и так склонен к истощению (по причине Обычно - не склонен, а там где склонен - у меня патч в ядре, который shutdown_nice() (или как его...) делает - ибо узнать, что прибъёт memory manager - невозможно.
несоответствия process resource limits), зачем же его дополнительно истощать данными md-диска? Не понимаю логику, какой-то self foot shooting получается. self-shooting звался sendmail inside jail - как при O MaxDaemonChildren=260 и зажиме количества входящих коннектов до 60 в системе появилось >2000 процессов - не то, чтоб загадка природы (во всех мэилбоксах торчит форвард в ещё один - в итоге затык в i/o неслабый получается), но всё же - как-то слабо укладывается в голове.
-F file Create a vnode-backed (MD_VNODE) memory disk backed by file.
дык мне надо чтоб а) быстро-быстро и б) всё к (нужное подставить) исчезло после ребута.
Странно, я по Вашему первому письму подумал, что данные на диске как раз критичны... Критичны для работы, но восстановимы - это всего только набор бинарников и файл от read-only file-based database. А вот в кое-где люди почтовый спул держат в mfs...
Ну и кто сказал, что при -F file опять ядро не прибъёт mount_mfs? (вероятность сего поменьше будет - но наверняка больше 0 ).
вобщем - явно нужно чтоб была возможность делать процессы "неубиваемыми" - иначе жить смогут только связки "процесс1 смотрит, чтоб не убили процесс2, который смотрит, .... чтоб не убили процесс N, который смотрит, чтоб не убили процесс 1.
А тут спорить в Вами не буду, логика убиения по out-of-swap во фришке (как и во многих *NIX-подобных системах) - проста, неуправляема и несовершенна. Время Вообще не понимаю, почему не прибить тот процесс, который хочет получить ресурс? Или не дать сделать fork() в случае нехватки ресурсов. Короче - "дать по башке тем, кто шевелится", и не трогать то, что "никуда не бежит"
от времени появляются попытки решения этой проблемы, но в дерево пока никто еще ничего толкового на эту тему не закоммитил (наверное, потому, что универсального решения еще не придумали). Так что выход пока один - корректное распределение системных ресурсов. Когда нагрузка неравномерно-непредсказуемо расперделяется во времени между абсолютно разными и несвязанными частями (по сути "virtual hosting")- жестко зажав что-либо получим рост требований к общей производительности (и стоимости) системы. Без механизма приоритетов - оно очень неинтересно, особенно если нельзя дать "всё", и прибить по заранее заданному закону "всё что мешает" если ресурс понадобится где-либо ещё.
-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message