9.2.5 db causes high cpu? was: Re: BIND 9.2.5rc1 is now available.

Stefan Schmidt zaphodb--bind at zaphods.net
Mon Feb 21 12:11:24 UTC 2005


On Mon, Feb 21, 2005 at 11:13:03AM +0100, Brad Knowles wrote:
> 	Sorry, my bad.  OP == Original Poster.
Ahh, i see. 

> 	I don't think I'd make this a compile-time option.  One of the 
> good things about BIND is that it is capable of running both 
> authoritative and recursive services on the same process/IP address.
> 
> 	Many years ago, I recommended that people run split servers, 
> where you had recursive-only servers on one set of machines and 
> authoritative-only servers on another set, and you would not try to 
> mix the two services.  But there are some cases where people are 
> running machines in environments where the number of systems 
> available to them are limited, or where the number of IP addresses 
> are limited, and if you have a server like Nominum ANS or Nominum CNS 
> that is only capable of handling one job or the other but not both, 
> then you're screwed.
> 
> 	BIND allows you to handle non-optimal situations like this.  Some 
> other servers don't.  I consider this a key advantage of BIND.

I do too. I did not want to abolish _any_ BIND9 feature or default behaviour,
i just merely wanted to suggest that future BIND9 releases should have more
knobs to fiddle with either at compiletime or via configuration options.
Something like the possibility to change the underlying database backend, for
example to Berkeley DB hash or btree, the possibility to optimize the lookup
function for authorative or recursive-only mode or just to make the decision
whether to have views or not.

> 	However, this does tend to lead people to misconfigure their BIND 
> servers, so I think it would be a good idea for future versions of 
> BIND to come up in a "default secure" mode.  Whereby, if you 
> configure your server to be authoritative for any zones beyond the 
> standard ones for "0.0.127.in-addr.arpa." and "localhost.", then the 
> server should refuse to perform recursion.  Likewise, if you 
> configure the server to handle recursion, then it should refuse to 
> answer queries from outside your network, and any other things that 
> are normally appropriate for recursive-only servers.
> 
> 	In other words, instead of making recursive-only or 
> authoritative-only compile-time options, instead make them default 
> operational modes which are automatically detected and implemented by 
> the software, but allow people to explicitly configure their server 
> so as to provide both functions, if they do the right "wave a dead 
> chicken" dance.

I second that vote. Just wrote my reply on your previous block before that so
i'll let you have it as well. ;)

> >  I followed Jinmei's recommendation of disabling threads and trying 
> >to run just
> >  one BIND9 process at first. So i am currently measuring 2 BIND8 processes
> >  against 1 BIND9 process on two identical machines.
> 
> 	With threading disabled on the BIND9 process, so it should be 
> significantly slower than the two BIND8 processes, but at least you 
> should get a clearer picture as to what else is going on.

Thats right, threading is currently disabled with that one BIND9 process.

I did not yet reimplement the DNS-smokeping so i do not know whether or not it
is slower but it seems to get a slightly higher query-rate from the
loadbalancer and eats up just as much user cpu as the two BIND8 processes on
the other machine. Generally i would expect a singletasking application to
answer queries more quickly than when it is threaded.

> >                                                  Before that i switched the
> >  machine in question from running 2 BIND8 processes to 1 BIND9 processes but
> >  with threading enabled.
> 
> 	Which would be the normal operating mode to be expected on an SMP 
> machine, and where the one BIND9 process should theoretically come 
> pretty close to the performance of the pair of BIND8 processes on the 
> other machine.

Yes, and i definitely second your opinion that BIND9 should and could perform
better when threading on multiple CPUs - to me as one that does not frequently
dig around in BIND9 sourcecode it seems to have something to do with BIND9s
memory management when threads are enabled and not using internal malloc.

There should be more people on this list that are familiar with the internals
of BIND9 - i really would like to hear from you guys. Any Nominum employees
willing/able to give a short statement on how they did it with CNS maybe? ;)

	Stefan
-- 
Nicholai Sokolov : [after shooting Zombie dog] STAY!
- Resident Evil: Apocalypse


More information about the bind-workers mailing list