Performance issues

[Ulrich David]

Hi John,
I should say it depends the day... We have indeed peak every hour...  
sometimes the peak every hour is weak (< 0.1 second for a query),  
sometimes it's big (> 1sec for a query) and sometimes one or more  
happens at other time....
It's strange because some days we have no big peaks and some days we  
have a lot of big peaks (more than 1 seconds for a query) and it's  
not linked to the average number of queries in the day.

I want to test to change the cleaning interval. It's better to give a  
smaller value than 1 hour or a greater value to 1 hour? What are the  
effects for the clients (bad responses, better performance,...)?

On the graph below, we can see that we have hourly peaks as you say  
on Friday, but nearly no peak on Saturday. However we have more  
queries on saturday tha on Friday...
This two graphs doesn't contain some very high peaks we have  
sometimes (more than 7 seconds)...

Value are taken every 3 minutes and these below are average on 15  
minutes.



-- Binary/unsupported file stripped by Ecartis --
-- Err : No filename to use for decode, file stripped.
-- Type: image/png


-- Attached file included as plaintext by Ecartis --





-- Binary/unsupported file stripped by Ecartis --
-- Err : No filename to use for decode, file stripped.
-- Type: image/png


-- Binary/unsupported file stripped by Ecartis --
-- Err : No filename to use for decode, file stripped.
-- Type: image/png


-- Attached file included as plaintext by Ecartis --



Thanks

David


Le 15 sept. 07 =E0 20:31, John Hascall a =E9crit :

>
>
> Is this happening about every hour?
> We've seen this when named decides it is cleaning time.
> http://www.zytrax.com/books/dns/ch7/periodic.html#cleaning-interval
>
> John
>
>
>> Hi,
>>
>> We are running bind 9.3.3 on 1 hidden master and 2 slaves with 2GB
>> Ram and "old" 2GHz Xeon. We have 150 queries/s average on each slave
>> with 300 queries/s in max peak. On these servers we have about 150
>> "lights" zones with Authority. We have done 2 views, one for our
>> client (about 20'000 in peak) which is open for recursives queries
>> and one for external which provide only the zones we have authority
>> on (no cache for it).
>> For example of queries repartition, at 20h00 yesterday we have
>> about : 5 failures/s, 70 recursives/s, 40 nxdomain/s, 5 nxrrset/s and
>> 150 success/s...
>>
>> We have some performance issue on the slaves. Sometimes the queries
>> on one of our authority zones (on one A record) can take some seconds
>> to be executed ! (in average it takes less than 8ms)... This
>> performance issues are not linked to load issues on server. We are
>> monitoring load (average load is 0,1 per minute), packets (average is
>> 150p/s), bandwith (average is 20kB/s), processus, ping time, ... The
>> bind performance issues can occure when we have only 150 queries/s
>> with a low load... we see nothing strange in the stats (like tcp or
>> udp explosions, or very high number of packets)...
>>
>> Are these issues "normal"? We are thinking about a solution with 2
>> front servers providing only cache services (open to our clients
>> only, for recursives) and with 2 slaves and 1 master dedicated to the
>> authoritatives zones (nor recursive, hidden to our clients). Could
>> this be a real solution for better performances?
>>
>> Regards
>>
>> David
>>
>> ##### some of our named.conf #####
>> # blacklist contains only 1 IP
>> # recursive is quite high... because
>> # sometimes 1000 recursives is not enough
>> ##############################
>> options {
>>          directory       "/etc/namedb";
>>          pid-file        "/var/run/named/pid";
>>          dump-file       "/var/dump/named_dump.db";
>>          statistics-file "/var/stats/named.stats";
>>          version         "None of your business";
>>          // we accept transfers only to our slaves
>>          allow-transfer {
>>                  key dns3-dns2.; # Our slave
>>                  key dns3-dns1.; # Our slave
>>          };
>>          recursive-clients 2500;
>>          blackhole { blacklist; };
>> };
>>
>> view "internal-in" in {
>>          match-clients { our_clients; };
>>          recursion yes;
>>          additional-from-auth yes;
>>          additional-from-cache yes;
>>          include "zones.conf";
>> };
>>
>> view "external-in" in {
>>          match-clients { any; };
>>          recursion no;
>>          additional-from-auth no;
>>          additional-from-cache no;
>>          include "zones.conf";
>> };
>>
>>
>

Ulrich David
Sierre-=C9nergie
david.ulrich at siesa.ch