новости книги игры
библиотека программы форум

11.05 11.10 1C 2010 2011 3d Acer action Additional Adobe alt linux ALT линукс в школу altlinux amarok AMD Android Apache apple apt-get ArchLinux asplinux ASUS Asus Eee PC ATI audio avi backup bash beta big buck bunny bind bittorrent blender bluetooth bsd c C++ Calibre Canonical cd Cedega CentOS chrome chromium cisco clamav CLI Damn Small Linux debian Deepin Dell desktop dns DOOM DOS download driver dvd e-book Eclipse emacs embedded linux enterprise EPUB Etersoft exim ext2 ext3 ext4 faq FB2 fedora fedora10 fedora8 fedora9 fedoracore firefox firefox3 firewall Flash Fluxbox flv free FreeBSD freeware ftp games gcc gentoo GIMP gnome GNU gnu linux google GPL GRUB gtk GTK+ hackday hdd


   

«    Май 2008    »
ПнВтСрЧтПтСбВс
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 

Каков ваш возраст?

До 14
14-16
16-18
18-21
21-25
25-30
30-40
40-50
От 50



LinuxTwitter:




Архив:

Июль 2012 (26)
Октябрь 2011 (91)
Октябрь 2010 (42)
Апрель 2010 (10)
Январь 2010 (29)
Декабрь 2009 (6)
Ноябрь 2009 (31)
Октябрь 2009 (20)
Апрель 2009 (19)
Март 2009 (1)
Февраль 2009 (20)
Январь 2009 (31)
Декабрь 2008 (71)
Ноябрь 2008 (89)
Октябрь 2008 (91)
Сентябрь 2008 (113)
Август 2008 (168)
Июль 2008 (156)
Июнь 2008 (147)
Май 2008 (191)
Апрель 2008 (213)
Март 2008 (197)
Февраль 2008 (195)
Январь 2008 (112)
Декабрь 2007 (146)
Ноябрь 2007 (94)




Партнёры:


Добавить в Google Reader
Читать в Yandex.Ленте
Mobile LinuxOpen (test version)

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

 Мне нравится:

До поры до времени я как и многие полагал что bind это хороший DNS сервер и искать ему замену смысла нет, к тому же во FreeBSD он в base system. Но выяснилось, что под большой нагрузкой в качестве кэширующего рекурсора bind9 работает просто отвратительно. Раз в cleaning-interval минут он чистит свой кеш от записей с истекшим TTL. Процедура это на редкость ресурсоемка - на кэше размером 256 Mb она занимает около минуты времени CPU (реального времени получается больше). И в течение этого времени он не отвечает на запросы. Оценить количество потерянных запросов можно, например, по счетчику "dropped due to full socket buffers" в netstat -s -p udp .

Почитал архивы [email protected] - оказалось, что проблема эта известная. Рекомендации по решению этой проблемы были такие:

  1. Собрать bind с ISC_MEM_USE_INTERNAL_MALLOC=1
  2. Уменьшить DNS_CACHE_CLEANERINCREMENT в lib/dns/cache.c

1-й пункт это использование встроенного аллокатора bind вместо системного malloc(). Попробовал. Ничего не изменилось. Очистка кэша осталось такой же неоправданно ресурсоемкой операцией как и с системным malloc().

2.-й пункт. Сам процесс очистки записей разбит на итерации. Т. е. проверяются не все записи подряд, а по DNS_CACHE_CLEANERINCREMENT штук, по умолчанию это 1000. В перерывах между отдельными итерациями он что то еще делает, возможно даже отвечает на часть запросов, но в целом они идут практически одна за другой. Пробовал уменьшать это значение до 200. Потерянных запросов стало меньше, но все равно больше половины.

Увеличил в добавок к этому net.inet.udp.recvspace - количество потерь еще немного уменьшилось - во ремя чистки кеша теряется порядка половины запросов.

Тестирование

В связи с этим решил протестировать другие сервера: PowerDNS Recursor и MaraDNS

Тест проводился так было сделано 3 файла по 65024 ip в каждом (все ip разные). И потом эти три файла одновременно ресолвились утилитой ip2host и наблюдалась сколько ресурсов кушает dns-сервер.

ip2host /dev/null&
ip2host /dev/null&
ip2host /dev/null&

И потом второй проход для получения того же, но уже из кеша.

Результаты получились такие:

Сервер cpu time (секунд) при получении записей которых нет в кэше

cpu time (секунд) при получении записей из кэша

Занимаемая память (RES), Mb
total user system total user system
bind9.3.2 61 48.01 12.99 18.81 14.01 4.8 118
PowerDNS recursor 3.1.4 88.01 70.86 17.15 33.35 27.45 5.9 46
MaraDNS 1.2.12.04 103.01 87.05 15.96 60.22 54.86 5.36 95

Т. е. при нормальной работе лучшем оказался bind, немного похуже pdns recursor и совсем плохо MaraDNS, что вполне логично если учитывать модели их работы.

Модель обработки соединений

  • bind - использует FSM (конечный автомат). Для все запросов к внешним серверам используется один и тот же сокет. Что позволяет в минимальном варианте держать постоянно открытыми всего два сокета - на 53-м порту, чтобы принимать запросы от клиентов и второй сокет для запросов к внешним серверам. Для их опроса используется select() который при всего двух дескрипторах работает эффективно (если их много select неэффективен).
  • pdns recursor - тоже использует FSM, но на каждый исходящий запрос открывает новый сокет. Это делает его более устойчивым к отравлению кэша, но требует немного больше ресурсов. Для опроса сокетов под FreeBSD используется kqueue()
  • MaraDNS - использует тредовую модель (!). Сколько одновременных выполняемых запросов столько и потоков. Вполне логично, что это сопряжено с большими накладными расходами.

Очистка кеша

  • bind - описано выше. т. е. очень плохо, что подтверждается практикой.
  • pdns recursor - раз в 10 минут проходится 10000 записей. Проверить в синтетических тестах это сложно, но по все видимости процесс очистки кеша не должен вызывать проблем т. к. за раз проверяется не весь кеш а только 10 тысяч (т. е. сравнительно небольшая часть кеша)
  • MaraDNS - на практике так же не тестировалось, но модель хорошая - никаких периодических чисток нет. Вместо этого когда не хватает места для новой записи просто удаляется несколько старых записей. Если они отсортированы по "time to die" то это требует очень мало ресурсов. Модель очень хорошая (так например делает memcached), но реализована, насколько я понял не очень хорошо.

Поддержка стандартов

  • bind - кроме того, что это самый распространенный DNS сервер это еще и reference implementation, т. е. если где то стандарт можно толковать по разному, то делать надо так как это сделано в bind. Поддерживает кучу разных нужных и не очень расширений протокола DNS (в папке doc лежит 96 RFC).
  • pdn recursor - серьезных проблем не замечено. Есть настройки которые делают его поведение не полностью стандартным, но это вполне осмыслено.
  • MaraDNS - похоже у автора излишне творческое отношение к стандартам. В частности если прописано несколько одинаковых записей он (dns roud robin) он отдает не все, а только часть из них (из за ограничений структур данных).

Что хочется

А хочется кэширующий DNS сервер который использует модель обработки соединений как в bind и организацию кэша подобно тому как это сделано в memcached : при запросе если запись есть в кэше проверять её TTL - если не истек отдавать клиенту и обновлять метку last used, если истек то удалять и заново спрашивать у удаленных серверов. Если в кеше не хватает места удалять по LRU - т. е. удалять те записи, которые давно никто не спрашивал.
P.S. djbdns пока не смотрел, но зная другие творения доктора Бернштейна, ничего хорошего ждать не приходится.

Anton Yuzhaninov

источник статьи   


26 мая 2008  /   /   ]

Похожие статьи

  • Открыто бета-тестирование DNS-сервера BIND 9.5.0
  • BIND9 - режим MASTER/SLAVE
  • DNS и BIND, 5-е издание
  • Ubuntu 8.10 впечатления о рабочей ОС
  • Производительность BIND в разных ОС




  • Комментировать:



     ©2007 - 2012 @antropoff.ru