Кэширующие рекурсивные DNS или чем плох bind9
Чем плох bind9
До поры до времени я как и многие полагал что bind это хороший DNS сервер и искать ему замену смысла нет, к тому же во FreeBSD он в base system. Но выяснилось, что под большой нагрузкой в качестве кэширующего рекурсора bind9 работает просто отвратительно. ( Read more... )
До поры до времени я как и многие полагал что bind это хороший DNS сервер и искать ему замену смысла нет, к тому же во FreeBSD он в base system. Но выяснилось, что под большой нагрузкой в качестве кэширующего рекурсора bind9 работает просто отвратительно. ( Read more... )
правило работают хуже FSM (и имеют больше проблем с надежностью). Другое дело что на FSM не все задачи можно положить (без титанических усилий), но рекурсивный DNS хорошо реализуется в виде FSM. Что и сделано в bind и Powerdnsd. Будет время и pdnsd протестирую. Но пока кандидаты production это powerdns recursor и maradns (он хоть и тредовый но с кешем по описанию хорошо работает).
Что касается djbdnsd то он уже 5 лет не поддерживается и у него дурацкая лицензия, которая не позволяет распространять измененный код. Часть его недостатков описано тут
Пока кандидаты в production это PowerDNS recursor и MaraDNS, но
требуется дополнительное тестирование, изучение их исходного кода и
изучение степени соответствия стандартам. bind используется
практически повсеместно, и если что то не может проресолвить bind это
не сможет проресолвить большинство. При этом вполне могут существовать
хосты которые не смогут корректно проресолить Power и Mara, т. к. они
сравнительно редко используются и такие проблемы могут быть долго не
замеченными. И это необязательно могут быть ошибки в софте, это может
быть и какое ни будь сочетание настроек разных удаленных DNS серверов.
Что касается bind то есть еще такой негативный с моей точки зрения момент - доступ к CVS только платный, открытого доступа к RT (bug tracker) нет и не планируется. Т. е. постороннему человеку подключиться к процессу разработки очень сложно.
Reply
Буду ждать тестирования. Интересно. Пишите результаты ;-)
Reply
Что касается того, что не параллелится то параллелить нужно только тогда когда есть блокирующиеся операции. Сокеты умеют работать в неблокирующемся режиме, дисковые операции кэширующему dns не нужны, задач которые требуют длительной работы CPU при правильном дизайне тоже быть не должно.
Безусловно у FSM есть свои недостатки, но в такой задаче как кэширующий dns проявляется только один из них (и то не в полной мере) - более ысокая сложность реализации, по сравнению с тредовой моделью.
Reply
При обработке рекурсивного dns-запроса тредовым приложением поток посылает запрос к удаленному серверу, потом ждет ответа (или таймауа). когда получит ответ пишет его в кэш и отвечает клиенту. В итоге получается, что большинство потоков у нас ничего не делают и находятся в состоянии ожидания ответа от удаленного сервера. Потоки конечно гораздо более легкий объект чем процесс, но с ними все равно сопряжены определенные накладные расходы. Я где то в рассылках freebsd видел результаты тестов, по которым на однопроцессорной машине bind9 с двумя потоками работает чуть ли на в полтора раза медленнее чем с одним.
Применительно к модели по которой стоит писать кэширующий dns весьма кстати такая цитата:
"A computer is a state machine. Threads are for people who can't program state machines."
-- Alan Cox
Reply
Пожалуйста поясните где можно почитать точно что именно попадает в этот и другие счётчики. Для ФриБСД.
Спасибо.
Reply
Почитать можно в /usr/src/sys/netinet/udp_usrreq.c
Каждый входящий пакет в udp_append помещается во входную очередь сокета. Если очередь переполнена (её размер задается через net.inet.udp.recvspace) или в системе недостаточно mbuf-ов, то пакет теряется и увеличивается счетчик udpstat.udps_fullsock.
Если очередь имеет достаточный размер, и mbuf-ов хватает, то быстрый рост udpstat.udps_fullsock говорит, о том, что приложение открывшее сокет читает оттуда данные медленнее чем они туда поступают.
Reply
Reply
Reply
Leave a comment