Comments | ospf_ripe: Кэширующие рекурсивные DNS или чем плох bind9

ospf_ripe

Кэширующие рекурсивные DNS или чем плох bind9

Dec 22, 2006 16:55

Чем плох bind9

До поры до времени я как и многие полагал что bind это хороший DNS сервер и искать ему замену смысла нет, к тому же во FreeBSD он в base system. Но выяснилось, что под большой нагрузкой в качестве кэширующего рекурсора bind9 работает просто отвратительно. ( Read more... )

bind, dns

Comments 25

brj December 22 2006, 18:21:59 UTC

http://www.phys.uu.nl/~rombouts/pdnsd.html ?

ospf_ripe December 22 2006, 20:26:36 UTC

pdnsd пока не смотрел, но он тредовый. А тредовые приложения как
правило работают хуже FSM (и имеют больше проблем с надежностью). Другое дело что на FSM не все задачи можно положить (без титанических усилий), но рекурсивный DNS хорошо реализуется в виде FSM. Что и сделано в bind и Powerdnsd. Будет время и pdnsd протестирую. Но пока кандидаты production это powerdns recursor и maradns (он хоть и тредовый но с кешем по описанию хорошо работает).
Что касается djbdnsd то он уже 5 лет не поддерживается и у него дурацкая лицензия, которая не позволяет распространять измененный код. Часть его недостатков описано тутПока кандидаты в production это PowerDNS recursor и MaraDNS, но ( ... )

brj December 23 2006, 23:07:48 UTC

FSM, на сколько знаю, никак не масштабируется и не параллелится.

Буду ждать тестирования. Интересно. Пишите результаты ;-)

ospf_ripe December 24 2006, 08:53:47 UTC

Правильно приготовленная FSM масштабируется очень хорошо. Да, в случае SMP чтобы использовать все процессоры нужно либо форкать несколько процессов (как это делает nginx) или создавать несколько потоков (как это умеет bind9, но пока работа в тредовом режиме там реализована плохо).

Что касается того, что не параллелится то параллелить нужно только тогда когда есть блокирующиеся операции. Сокеты умеют работать в неблокирующемся режиме, дисковые операции кэширующему dns не нужны, задач которые требуют длительной работы CPU при правильном дизайне тоже быть не должно.

Безусловно у FSM есть свои недостатки, но в такой задаче как кэширующий dns проявляется только один из них (и то не в полной мере) - более ысокая сложность реализации, по сравнению с тредовой моделью.

Thread 9

(The comment has been removed)

ospf_ripe December 24 2006, 20:06:02 UTC

Чтобы можно было использовать несколько процессоров на SMP, AFAIK
Во базовой системе FreeBSD не предусмотрена сборка с тредами даже через knob в make.conf...

ospf_ripe December 24 2006, 20:13:57 UTC

В ходе изучения проблемы с bind был написан маленький перловый скрипт, который пишет в лог когда дропаются udp пакеты. Чтобы видно было когда это происходит и можно было сопоставить это время с другими логами.
Может кому тоже пригодится

В качестве именно рекурсора lucky_rvp December 25 2006, 08:08:14 UTC

я бы рекомендовал пользовать таки djbdns - имею крайне позитивный опыт.
Переход от BIND к djbdns был вызван ужором CPU time.
C 90% cpu load на BIND ушли к >25% на djbdns
Организация - крупный телеком-ISP в Москве.

http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software

Re: В качестве именно рекурсора lucky_rvp December 25 2006, 08:56:07 UTC

+1
точно такая же ситуация, dnscache спас от "high CPU load"
правда сначало это привело к значительным нагрузкам на IO т.к. по умолчанию dnscache логирует все запросы, но как только эта возможнасть была отключена
загрузка серверов (2 рекурсивных DNS сервера) упала на порядок.

Re: В качестве именно рекурсора lucky_rvp December 25 2006, 09:08:24 UTC

ну тема с логгингом всего ився по дефолту в литературе, я считаю, раскрыта хорошо :-)))

http://www.tnpi.biz/internet/dns/djbdns-freebsd.shtml

It should also be noted that you are still piping logs from dnscache to multilog which then discards them. If your CPU is pegged and you want a bit more of a performance tweak, edit the dnscache/run file and change "exec 2>&1" to "exec 1>/dev/null 2>&1". That entirely disables any and all logging.

Re: В качестве именно рекурсора ospf_ripe December 25 2006, 09:20:06 UTC

djbdns не нравится тем, что он уже 5 лет не поддерживается. Некоторые хосты он может ресолвить только с дополнительными патчами. А лицензия не позволяет сделать форк от djbdns и развивать его. В общем это мертвый проект, и мертвый не в последнюю очередь из за лицензии.

Thread 7

ra_ga December 27 2006, 08:23:33 UTC

картинка следующая:
SunOS e22 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-60
bind 9.3.3 в кач-ве кеширующего нса, запущен с -n 2, собран с тредами.
Спустя некоторое время(дня 3-4) он отжирает где-то около гига памяти и %40 cpu. При этом в часы пик среднее время ответа доходит до 40-60мс(пока бинд не разжиреет, такого не наблюдается).

Вопрос: имеет ли смысл собрать бинд без тредов и пускать 2 экземпляра (на разных адресах) с -n 1 но с привязкой по процессорам и ограничением datasize?

ospf_ripe December 27 2006, 10:58:11 UTC

Объем памяти лучше ограничить.
У нас стоит
max-cache-size 256M;
Чем больше объем кэша, тем больше загрузка CPU. А при маленьком маленький hit-rate. Поэтому нужно что то среднее. Я считаю, что больше 256Mb - 512Mb для bind'а ставить не стоит. С большим кешем bind плохо работает.

Запускать 2 разных процесса смысла нет - у каждого будет свой независимый кэш и эффективность кэширования от этого упадет.