Производительность BIND в разных ОС

А так это были getthefacts от гентушнигов, тогда понятно...%)

> А, главное, я как страшный сон забыл проблемы дистапгрейдов. Более того, уже скоро год, как машина на полном автопилоте по обновлениям :)

Офигеть.. У меня как раз в генте по жизни проблемы были с изменением формата конфигов.. Кстати, hardened?

>И это продакшен?? Откройте для себя redhat

Иди и перечитай ещё раз, на чём я сидел до Gentoo :)

>А ты в это время был в отпуске за несколько тысяч км от сервера. В месте, где нет больной связи.

Когда я был в такой ситуации, я предварительно отключал автообновления. Неужели так трудно представить, что оно может копать, а может - не копать :D

>Офигеть.. У меня как раз в генте по жизни проблемы были с изменением формата конфигов..

На ~x86 - да. На x86 - ни разу не натыкался. Нет, возможно, если бы я весь год не делал etc-update, то рано или поздно конфиги бы поломались, но я его делаю периодически :)

Вообще, на грабли обновления конфигов я наступал дважды. Один раз - обновляя RH до упомянутого 7.3, когда они inet.d обновили до xinet.d - я потом полдня поднять продакшн-сервер не мог :D

Второй раз - как раз на Gentoo, но на десктопе, в ~2004-м, когда они формат /etc/conf.d/net поменяли.

>Кстати, hardened?

Нет, обычный. Основная часть системы - x86, некоторые компоненты - ~x86 (типа того же pyicq-t, ejabber и т.п.)

...

Да, кстати, огромный бонус Gentoo на сервере - webapps. Всякие RedHat и прочие аналога просто не имеют. Ручками обновлять шесть экземпляров Coppermine, три drupal'а, пять MediaWiki... Спасибо, у меня для этого комп есть, он железный :D

> неужто они намекают на то что такими темпами на серваках заменят бздю на gentoo?

Все грамотные уже давно поменяли, т.к. не место гнилой фряхе на сервере, когда есть gentoo.

> Генту и федорку взяли как самые тормозные дистры (дабы показать превосходство ядра) - всё остальное будет сверху. Ну а на первом месте конечно же божественая слака.

Юзаю генту, тормозов не замечал, откуда такое больное воображение?

p.s. Тест действительно реальный, в отличие от последних фанатичных тестов фряшнегов, не основывающихся на фактах.

> Тест действительно реальный

Естественно. FreeBSD-7-RC2 успевает за секунду более 93 DDNS апдейтов, а Генту -- 42 (Fedora около 20). На реальной .com зоне FreeBSD-7-RC1 обрабатывает более 75000 запросов в секунду, Gentoo около 70000. В общем, Генту почти (местами) догоняет на реальных задачах.

PS. К сожалению, релиз не тестировали, жаль.

>>webapps. Всякие RedHat и прочие аналога просто не имеют таки бросьте. в федоре есть эти приложения

Вот посвежее: http://new.isc.org/proj/dnsperf/ISC-TN-2008-1.html

"Rate at which BIND 9.4.1-P1 can handle DDNS updates to unsigned zone files, updates/second"

OS -- COM 1st half -- COM 2nd half

FreeBSD-7-RC2 -- 93.46 -- 82.85
FreeBSD-6.2-Stable --89.52 -- 77.34
FreeBSD-6.2-Release --471.70 -- 446.23
NetBSD-4-Current -- 80.32 -- 81.77
Solaris-10 edition of 5/07 -- 87.80 -- 83.54
Solaris-10 eidtion of 8/07 -- 63.21 -- 64.10
Linux-Gentoo -- 42.07 -- 42.76
Linux-Fedora -- 22.29 -- 15.07

Всё тут хорошо, но только вот одно меня смущает, а где же информация о том, что тюнили эти животные из ISC, не поверю в жизнь, что их мега админ, который делал тест все системы знает, как свои штаны в клеточьку, даёшь адекватные тесты, с конфигами и людьми из каждой команды ОС-и, которую тестируют, а не это красноглазие в стиле мелкомяхкого гетзефактс нигГа...]:->

Если почитать коментарии к тексту, то вылазит, что этот тест напрямую зависит от реальной скорости записи файловой системы, без учета кэша. Админы не тюниговали системы, все по умолчанию. Так вот, у фряхи 6й жопа... У остальных вполне предсказуемо - наличие журнала тормозит запись, ведь кроме записи в иноду и кластер надо ещё и в журнале отметится. Федора так сливает судя по всему от большой любви к ext3.

> Вот посвежее: http://new.isc.org/proj/dnsperf/ISC-TN-2008-1.html

Вообщето это не посвежее, а совсем другой тест "Updates of the master server"

> Если почитать коментарии к тексту, то вылазит, что этот тест напрямую зависит от реальной скорости записи файловой системы, без учета кэша.

> Так вот, у фряхи 6й жопа...

Не у неё, а у собранного под ней bind. Собрался без fsync, а переделывать не захотели. Да и не актуально, ибо после релиза 6.2 и несколько -pXX вышло, и 6.3-RELEASE.

> этот тест напрямую зависит от реальной скорости записи файловой системы

То есть основной аргумент сейчас будет, "так не честно, у FreeBSD FS быстрее"? Или, "журналирующие FS сосут по сравнению с UFS2+SU"? :-)))

сосут "журналирующие FS" или не сосут. и что они там сосут это науке не известно. Но точно известно, что soft-updates никаким боком к скорости записи не относится. В конкретном тесте не журналирующие FS выиграли. Если бы работал кэш, то файловая система бы работала на полной скорости. В соседней ветке, про ext4 много чего по теме написано. В частности, что если бы тест проводился по FAT16 то именно на ней бы было первое место :)

в топку опрос, где slackware? желательно чтобы со slack-build собранная?

> Если почитать коментарии к тексту, то вылазит, что этот тест напрямую зависит от реальной скорости записи файловой системы, без учета кэша. Админы не тюниговали системы, все по умолчанию.

Вот и всё, я ж говорю животные, не думал, что ISC опуститься до такого банального мелкомяхкого геизефактс нигГа!!!:(

> у нас. крайне отвратно оно ведёт себя в таком варианте под нагрузкой. > 1-1500 рекурсивных запросов в секунду и время ответа плавно начинает расти в бесконечность.

ну странно, 2k я указал чтобы отсечь нижнюю часть. А вообще у меня 4k средняя рекурсивных нагрузка, и ничего, нормально справляется. может вы его (named) "готовить не умеете" ?

>Почему 2.6.20? Всегда удивляюсь - почему старые ядра?

патамучта работает, не трожь!