Benchmark DNS cache – problemy.

Jakiś czas temu zainteresowałem się, głównie za sprawą prezentacji Infoblox na 9 PLNOG nt. DNS, tematem DNS cache i jego wydajności. Nie jest to zupełnie nowa sprawa, bo kiedyś otarłem się o problem wydajności DNS cache (albo raczej sprzętu, na którym działało to jako jedna z wielu usług…). Skończyło się tak, że mały i lekki dnsmasq jest za mały dla większej osiedlówki, choć nadal fajny w rozwiązaniach domowych.

Pierwsze skojarzenie z DNS to oczywiście bind, którego „wszyscy znają, wszyscy używają i nadaje się do wszystkiego”. Autorzy unbound przekonują, że to niekoniecznie dobre podejście, więc – zachęcony tym, co znalazłem w sieci – postanowiłem przetestować wydajność bind vs. unbound.

Nie ma lekko. W Debianie nie znajdziemy gotowego pakietu z narzędziem do testowania wydajności serwera DNS. W ogóle nie ma (nie znalazłem) wydajnego narzędzia do tego. Jest queryperf, dostępny w źródłach bind (do samodzielnej kompilacji), ale do wydajności mu daleko – często obciąża maszynę porównywalnie, jeśli nie bardziej, niż sam testowany program. W prezentacji (http://www.infoblox.nl/content/dam/infoblox/documents/solution-notes/infoblox-note-ib-2000-performance-test.pdf – dead link) znalazłem skrypt:

#!/b in/sh
SECS=5
INPUT=qp.forward.master.cached
SERVER=10.34.31.2
# SECS is number of seconds to run test
# INPUT is input file
# SERVER is server IP
queryperf -s $SERVER -d $INPUT -l $SECS > out1 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out2 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out3 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out4 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out5 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out6 2>&1 &
wait
grep ‘Queries per’ out? | awk ‘BEGIN { sum=0;}{ sum += $5;}
END {printf(“Total: %.1f qps\n”, sum);}’


Szybkie zapytanie na kanale IRC i… jedna osoba zgłasza, że przesiadła się na unbound i jest zadowolona; sugestii co do oprogramowania testującego brak, za to pojawia się koncert życzeń: jak już to jeszcze przetestować pnds_recursor, djbdns… i może bind10, bo podobno poprawiona wydajność. Robi się tego sporo, bo i lab z paroma maszynami wysyłającymi zapytania by się przydał, i testowanych demonów większa ilość. A miało być szybkie i proste zagadnienie na 1-2h.

Do tego problem danych testowych – każdy ma u siebie nieco inną charakterystykę ruchu, wyniki mogą się różnić dość znacznie, więc skąd wziąć dane? Jasne, można benchmarkować na podstawie własnych, rzeczywistych danych i będzie to najbliższe optymalizacji w danym przypadku, ale czy wartościowe dla innych? No i na pewno nie opublikuję takiego testowego zestawu danych. Jest też problem dostosowania konfiguracji do konkretnej platformy, na której uruchamiane będzie oprogramowanie (np. ilość wątków). Domyślny konfig jest różny dla różnych demonów, przy czym domyślny debianowy dla unbound ma się nijak do maszyny wieloprocesorowej. No i przydał by się tuning samego systemu pod kątem wydajności sieci, bo default w Linuksie jest raczej słaby.

Więcej pytań, niż odpowiedzi. Stanęło na tym, że pełnego testu nie zrobiłem. Za to puściłem szybki test na jakimś małym zestawie danych (kilkanaście wpisów). W ww. skrypcie zmieniłem liczbę procesów na 4, czas na 60 sekund i testowałem na laptopie (Intel Core i5). Nie do końca optymalnie, ale cóż, lepiej, niż pojedynczy proces. Poprzestałem więc na tym pseudobenchmarku na domyślnym konfigu – zabawa w optymalizację to grubsza sprawa, jeśli ma być zrobiona porządnie. Unbound wypadł bardzo dobrze. Mimo, że działał tylko na pojedynczym rdzeniu, wypadł dwukrotnie lepiej, niż bind.

Nie ukrywam, że chętnie poznam sugestie dot. danych testowych (takich, które można opublikować) i ew. doświadczeń z benchmarkowaniem DNS (cache). Jeśli się zbiorę i zrobię benchmark, to dane i wyniki będą opublikowane. Na razie stanęło na tym, że na moich dekstopach zmieniłem bind na unbound (tak, mam lokalne cache na desktopach od jakiegoś czasu, raczej eksperyment, kiedyś napiszę na ten temat).

4 odpowiedzi na “Benchmark DNS cache – problemy.”

  1. Z tego co pamiętam chodziło o dns-forward-max:
    can be increased: start with it equal to
    the number of clients and increase if DNS seems slow. Note that DNS
    performance depends too on the performance of the upstream
    nameservers. The size of the DNS cache may be increased: the hard
    limit is 10000 names and the default (150) is very low. Sending
    SIGUSR1 to dnsmasq makes it log information which is useful for tuning
    the cache size.

    I kojarzy mi się, że wtedy hard limit był 1000 czy 1500. W każdym razie dla osiedlówki z duże kilkaset hostów po zwiększeniu do dozwolonego maksimum nadal się nie wyrabiał. Tak, nie był to typowy ruch. Ale wypadałoby obsłużyć. 😉

  2. Temat ciekawy. Nie mam doświadczenia z osiedlówkami ale u mnie po kilku dniach, na laptopie, to wygląda tak:

    Mar 11 21:48:14 domino dnsmasq[31777]: wielkość pamięci podręcznej: 1500; 0 z 4608 miejsc aktualnych wpisów użyto ponownie.
    Mar 11 21:48:14 domino dnsmasq[31777]: 3257 zapytań przesłanych dalej, 1100 odpowiedzi udzielonych samodzielnie
    Mar 11 21:48:14 domino dnsmasq[31777]: serwer 127.0.0.1#55: 3257 zapytań wysłanych, 244 ponowionych lub nieudanych

    – a ja wyłączam w FF prefetching adresów, sprawdzanie URL-i w bazach zgłoszonych oszustw i mam dodatek request policy(choć muszę sprawdzić czy ten dodatek zapobiega też dodatkowym zapytaniom DNS).

    Ciekaw jestem jak to wyglądało by więc dla sieci z 100+ hostami i takimi typowymi userami :). Lokalnie, w połączeniu z dnscrypt-proxy, działa to super.

    PS. Skasowałem plik dnsmasq.mo jednak wolę mieć logi po angielsku. 🙂
    PS2. Nigdy nie korzystam z DNS-ów dostawcy, to po dawnych doświadczeniach z Neostradą: jeden ich serwer DNS ustawiony przez DHCP zawsze nie odpowiadał i nie tylko u mnie to zaobserwowałem wtedy.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *