Tuning Bind9?

Rick Jones foo at bar.baz.invalid
Thu Jan 27 18:17:27 UTC 2005


fredrik.pettai at vattenfall.com wrote:
> We have bind 9(.2.x) on Solaris, since it's multithreaded and support =
> incremental updates.

> However, then we do _big_ zone-transfers of a hole zone (for example =
> RBL-zones), the name-resulotion (queries) becomes really slow, and those =
> zone-transfers can take a long time if you need to transfer the hole =
> zone.
> As i can see, there is only 4 threads working on the server but only =
> about 20% of cpu-usage totally during the heavy zone-tranfers (and no =
> other bottlenecks in the systemem that i can see...)

How many and what type of CPUs are there on the server, and is the CPU
usage of any one of the threads close to a full CPU's worth?

How large is the whole zone you are transferring?  

How long does it take to transfer the zone?

How slow do the queries become?  

Do clients have to retransmit their requests?

Do the TCP_level stats on the server show retransmissions while
transfering the zone?

Do the link-level stats on the server show packet losses?

> Is it possible to trim bind so it have a chance to answer the queries =
> faster then a _big_ zone-transfer is in progress? I searched for ways of =
> increasing the the threads, but i found nothing. I've checked the =
> disk/mem/network connection of the machine and those things seems to be =
> quite enought. So i don't think it's a limit of the machine that makes =
> this "slowniness" during the _big_ zone-transfers...
> I didn't find any useful parameters to add i the configuration-file =
> either.
> Has someone else had this problem? and solved it?

I suppose you might consider setting the minimal responses flag so the
server does less "I think you may need this" work forming responses.

rick jones
-- 
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...



More information about the bind-users mailing list