Привет! On Sun, 9 Jul 2006, Paul Arakelyan wrote:
mdmfs -s 512m md /mnt dd if=/dev/zero of=/mnt/aaa bs=1m У меня туда 1 раз "заливается" несколько файлов - "и всё". Далее - только читается. В принципе - мне нужно гарантированное торчание этого MFS в памяти...
Так в памяти (RAM) или в (RAM+swap)? Ведь '-s' дает именно 2й вариант. Если Вы внимательно посмотрите на результат эксперимента, который я предложил, Вы это "легко увидите" (TM): /dev/md0 507630 507156 -40136 109% /mnt ------------------------^^^^^^ root@homelynx# swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s4b 1048576 222908 825668 21% ----------------------------^^^^^^ Своп тут действует точно так же, как для процесса: выделяем свободные странички в RAM, истощили process limit или system-wide free page list (как в нашем случае) - тогда уже сливаем остальное в потенциально медленное swap device. Вы думаете, где 507156-222908 кб? top дает ответ: Mem: 308M Active Грохнул md0 - тут же 32M в active осталось. Если Вам нужно только RAM утилизировать, так -M Create a malloc(9) backed disk (MD_MALLOC) instead of a swap- backed disk.
несоответствия process resource limits), зачем же его дополнительно истощать данными md-диска? Не понимаю логику, какой-то self foot shooting получается. self-shooting звался sendmail inside jail - как при O MaxDaemonChildren=260 и зажиме количества входящих коннектов до 60 в системе появилось >2000 процессов - не то, чтоб загадка природы (во всех мэилбоксах торчит форвард в ещё один - в итоге затык в i/o неслабый получается), но всё же - как-то слабо укладывается в голове.
Я при define(`confDELIVERY_MODE', `queued') такого не наблюдал. При режиме по-умолчанию (deliver in background (asynchronously)) - наблюдал, и, наверное, слово asynchronously помогает "уложить в голове" этот факт. Письмо влили - сразу же доставляем, без постановки в очередь. Как при такой логике работы можно ожидать исполнения O MaxDaemonChildren, если письма льют сплошным потоком? Вот при queued все нормально, мастер поднимает разгребателей очереди не более, чем разрешено ограничением.
Критичны для работы, но восстановимы - это всего только набор бинарников и файл от read-only file-based database. А вот в кое-где люди почтовый спул держат в mfs...
IMHO плохие люди, негодные. Если их UPS не выдержал издевательства работников горэлектро, и после перезагрузки их почтовик "забыл" транзитные письма на домен важного клиента, которые были в спуле, пока клиент тоже валялся - именно им клиент по головушке настучит, и именно за такой дизайн почтовой системы. И будет прав. Письмо в спуле - это что, второй сорт?!
Вообще не понимаю, почему не прибить тот процесс, который хочет получить ресурс? Или не дать сделать fork() в случае нехватки ресурсов. Короче - "дать по башке тем, кто шевелится", и не трогать то, что "никуда не бежит"
Хи-хи. Разобрать ресурс "под завязку" может один процесс, а памяти (немного, но у системы ее уже нет) потребовать абсолютно другой. Системе нужно как-то вернуться в нормальный режим работы. Единственный способ - прибить кого-то из тех, кто съел ресурс. Сейчас AFAIK так и делается - ищется процесс с максимальным потреблением памяти и прибивается.
(и стоимости) системы. Без механизма приоритетов - оно очень неинтересно, особенно если нельзя дать "всё", и прибить по заранее заданному закону "всё что мешает" если ресурс понадобится где-либо ещё.
Приоритеты в выделении свопа? А такое где-нибудь есть? Я такого даже в OpenVMS не видел, не то что в *NIX-системах. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message