Под нагрузкой (нэажиданной проста :)) бесследно испарился диск в MFS. Кончилась память немного - и его /kernel: pid ххх (mount_mfs), uid 0, was killed: out of swap space Неожиданный поворот, да? -- 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
Привет! On Fri, 7 Jul 2006, Paul Arakelyan wrote:
Под нагрузкой (нэажиданной проста :)) бесследно испарился диск в MFS. Кончилась память немного - и его /kernel: pid ххх (mount_mfs), uid 0, was killed: out of swap space
Неожиданный поворот, да?
Абсолютно ожиданный: root@test# man mount_mfs ... By default, mdmfs creates a swap-based (MD_SWAP) disk ... Вы уж, если выбираете backing storage = swap (которая volatile by definition), либо гарантируйте неистощаемость этой storage, либо используйте другую storage, например, эту: -F file Create a vnode-backed (MD_VNODE) memory disk backed by file.
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
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
On Fri, Jul 07, 2006 at 01:05:20PM +0300, Dmitry Pryanishnikov wrote:
Привет!
On Fri, 7 Jul 2006, Paul Arakelyan wrote:
Под нагрузкой (нэажиданной проста :)) бесследно испарился диск в MFS. Кончилась память немного - и его /kernel: pid ххх (mount_mfs), uid 0, was killed: out of swap space
Неожиданный поворот, да?
Абсолютно ожиданный:
root@test# man mount_mfs ... By default, mdmfs creates a swap-based (MD_SWAP) disk ...
Эт всё хорошо, но "без спросу" отрывать диск с открытыми файлами - это как-то неправильно. Короче, "потрясающий менеджмент ресурсов".
Вы уж, если выбираете backing storage = swap (которая volatile by definition), либо гарантируйте неистощаемость этой storage, либо используйте другую Стоп - я "отожрал" заданный кусок памяти - и "дальше - хоть потоп", диск же не наращивается в объёме - зачем тогда "неистощаемость ресурсов"?
storage, например, эту:
-F file Create a vnode-backed (MD_VNODE) memory disk backed by file. дык мне надо чтоб а) быстро-быстро и б) всё к (нужное подставить) исчезло после ребута. Ну и кто сказал, что при -F file опять ядро не прибъёт mount_mfs? (вероятность сего поменьше будет - но наверняка больше 0 ).
вобщем - явно нужно чтоб была возможность делать процессы "неубиваемыми" - иначе жить смогут только связки "процесс1 смотрит, чтоб не убили процесс2, который смотрит, .... чтоб не убили процесс N, который смотрит, чтоб не убили процесс 1. -- 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
Привет! 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 и понаблюдайте с другой консоли за тем, как swapinfo показывает реальное использование свопа Вашим диском. Так что "отжор" здесь производится динамически, при работе с диском. Своп, к сожалению, более критичный ресурс, чем свободное место на файловых системах. Если в Вашей системе он и так склонен к истощению (по причине несоответствия process resource limits), зачем же его дополнительно истощать данными md-диска? Не понимаю логику, какой-то self foot shooting получается.
-F file Create a vnode-backed (MD_VNODE) memory disk backed by file.
дык мне надо чтоб а) быстро-быстро и б) всё к (нужное подставить) исчезло после ребута.
Странно, я по Вашему первому письму подумал, что данные на диске как раз критичны...
Ну и кто сказал, что при -F file опять ядро не прибъёт mount_mfs? (вероятность сего поменьше будет - но наверняка больше 0 ).
вобщем - явно нужно чтоб была возможность делать процессы "неубиваемыми" - иначе жить смогут только связки "процесс1 смотрит, чтоб не убили процесс2, который смотрит, .... чтоб не убили процесс N, который смотрит, чтоб не убили процесс 1.
А тут спорить в Вами не буду, логика убиения по out-of-swap во фришке (как и во многих *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
On Sat, 8 Jul 2006, Paul Arakelyan wrote: Ну и кто сказал, что при -F file опять ядро не прибъёт mount_mfs? (вероятность сего поменьше будет - но наверняка больше 0 ).
Попытался на домашней 6.1-STABLE повторить Ваш эксперимент с переполнением свопа и swap-backed md - получается совсем другое поведение. Итак, свопа у меня 1G, готовимся к прострелу ноги: mdmfs -s 2g md /mnt В списке процессов никакого mount_mfs не видим; единственное, что видим - системный процесс 0 1131 0 0 -8 0 0 8 mdwait DL ?? 0:00.00 [md0] Стреляем в ногу: dd if=/dev/zero of=/mnt/aaa bs=1m С другой консоли запускаем top, видим, как своп исчерпывается. Далее ядро по очереди убило все процессы, кроме системных. Я смог опять зайти в систему, увидел, что мой диск и файл на нем - на месте, зато в свопе забит под завязку. Я издал umount /mnt, mdconfig -du0 - своп освободился. Система работает нормально, вот письмо из нее пишу. Так что, по крайней мере, RELENG_6 с данным видом форс-мажора, я считаю, справилась неплохо. Хотя конечно, если бы на ней крутилась та же zebra, она бы ее прибила (как прибила syslogd и named). Механизм "неубиваемых" процессов был бы очень полезен, не спорю. 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
On Sat, Jul 08, 2006 at 02:40:56PM +0300, Dmitry Pryanishnikov wrote:
On Sat, 8 Jul 2006, Paul Arakelyan wrote: Ну и кто сказал, что при -F file опять ядро не прибъёт mount_mfs? (вероятность сего поменьше будет - но наверняка больше 0 ).
Попытался на домашней 6.1-STABLE повторить Ваш эксперимент с переполнением свопа и swap-backed md - получается совсем другое поведение. Итак, свопа у меня 1G, готовимся к прострелу ноги:
mdmfs -s 2g md /mnt
То, на чём оно случилось 4.11-STABLE #0: Thu Jan 27 2005 mount_mfs -o noatime -b 32768 -f 4096 -i 131072 -s 131072 /dev/ad0s1b /mfs
В списке процессов никакого mount_mfs не видим; единственное, что видим - системный процесс
0 1131 0 0 -8 0 0 8 mdwait DL ?? 0:00.00 [md0]
Стреляем в ногу:
dd if=/dev/zero of=/mnt/aaa bs=1m симуляция скорее должна выглядеть так: заливаем эдак 100MB в mfs, затем запускаем что-то, что оттуда будет читать в несколько потоков (типа while() с dd if=/mnt/что-то внутри), оставляем так на пару часиков.
Потом создаём кучу процессов, сжирающую память - например while() do dd if=/dev/ad0 of=/dev/null bs=16384000 & done
С другой консоли запускаем top, видим, как своп исчерпывается. Далее ядро по очереди убило все процессы, кроме системных. Я смог опять зайти в систему, увидел, что мой диск и файл на нем - на месте, зато в свопе забит Прикол именно в том, что то, что активно работало и жрало ресурсы - так и продолжило успешно жить и работать.
под завязку. Я издал umount /mnt, mdconfig -du0 - своп освободился. Система работает нормально, вот письмо из нее пишу. Так что, по крайней мере, RELENG_6 с данным видом форс-мажора, я считаю, справилась неплохо. Хотя MFS по идее по-разному реализован в 6.0 и в 4.х, в своё время 5.х вешались при записи в mfs (типа распаковать ports collection - и довольно быстро в процессе всё вешалось). Возможно именно эта разница и спасла. А может - "просто повезло".
конечно, если бы на ней крутилась та же zebra, она бы ее прибила (как прибила syslogd и named). Механизм "неубиваемых" процессов был бы очень полезен, не спорю.
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
-- 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
On Sun, 9 Jul 2006, Paul Arakelyan wrote:
Попытался на домашней 6.1-STABLE повторить Ваш эксперимент с переполнением свопа и swap-backed md - получается совсем другое поведение. Итак, свопа у меня 1G, готовимся к прострелу ноги:
mdmfs -s 2g md /mnt
То, на чём оно случилось 4.11-STABLE #0: Thu Jan 27 2005
Да, в 4ке все может быть по-другому. И даже если бы мы с Вами нашли более оптимальный вариант поведения ядра для RELENG_4, его врядли кто-то из девелоперов стал бы рассматривать. Сейчас IMHO более актуально доводить 6ку до ума (до production quality - в моем представлении она еще не вполне соответствует этому определению по сравнению с 4кой). Однако в этом конкретном случае (переполнение свопа - как его корректно предотвращать и что делать, если оно таки наступило) я даже теоретически не представляю себе адекватного алгоритма. 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
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
Привет! 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
participants (2)
-
Dmitry Pryanishnikov -
Paul Arakelyan