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

Paul Vixie paul at vix.com
Mon Feb 21 17:29:07 UTC 2005

> From: Stefan Schmidt <zaphodb--bind at zaphods.net>
> ...
> 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.

that's precisely where the limits are, yes.

> 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? ;)

my very brief understanding of why CNS is so fast is that the authors put
some time and thought into understanding how to do retries and server
selection (from among multiple NS's each having multiple A's and AAAA's)

the data structures are also optimized for the job at hand -- and not
having authority zones or views in the way is a great simplifier.  but
if that was the only difference, then djbdns would be as fast as CNS.


> From: Brad Knowles <brad at stop.mail-abuse.org>
> ...
> 	The use of Berkeley DB or other alternative database back-end, I 
> think is something I would also prefer to be largely controlled 
> through configuration options, but obviously you can't pre-compile 
> with headers and libraries pre-linked for all possible database 
> backends.

there is a lot of interest out there in persistent dns caching, and in
what some people call "dns mirroring" that's really just a persistent
dns cache with search/dump capability.  at some point BIND will have
to support this, whether by SQL or DB or whatever means.

> 	I understand that a significant number of those people are no 
> longer working at Nominum, so if you could find a way to get them to 
> contribute work to BIND9, then I think we might be able to take 
> advantage of their experience.  However, these people do have to put 
> bread on the table, and not knowing where they are working today, I'd 
> have to say that a significant amount of funding would have to be 
> channeled through ISC to bring these people back into the process.
> 	Otherwise, the people who used to work at Nominum and have been 
> transferred back to ISC (and work on BIND9) is very limited, and ISC 
> just doesn't have the kinds of resources to fund work on BIND9 that 
> Nominum was able to put together for ANS and CNS.

with all due respect for the team at nominum who did ANS and CNS, who
did a fine job, and for the team at iengines/nominum who did BIND9.0.0,
who also did a fine job... one does not have to have done ANS, CNS, or
BIND9.0.0 to be valuable to BIND9-current, either as an ISC employee or
contractor or volunteer.  our primary metric is "clue".

the most important part of funding is recurrance.  which is not to say
that ISC wouldn't welcome more donations and grants and one-time software
development agreements -- WE WOULD! TAKE NOTE!  however, things like BIND
Forum memberships, and BIND support contracts, and as of this week DHCP
support contracts, is what it takes to permanently expand the staff...

...which we are very keen to do.  feel free to send me a resume if you're
interested in a "some day when we can afford it" BIND-related job and you
think you've got the skills and 'tude to work at ISC.


> From: Brad Knowles <brad at stop.mail-abuse.org>
> ...
> 	If you want to greatly speed up the code, I think you're going
> to have to do another ground-up redesign and eliminate the
> architectural issues that are holding back BIND9.

according to internal lab results i've seen in the last year, that's
just not true.  i don't think BIND9 will be beating ANS any time soon,
but if we can figure out how to do the release engineering for all the
stuff in the CVS pool, i think we'll be competitive with everybody else.

> >  Well it's an opensource project after all, how about interesting
> > more people - and there are many bright ones still out there - to
> > contribute to it?
> 	Brooks's "Mythical Man-Month" (see 
> <http://en.wikipedia.org/wiki/The_Mythical_Man-Month>) teaches us 
> that it's not just a matter of getting more people into the project.
> 	Our problem is getting more and better people into the project, 
> and finding the funding to make that happen.  I think that the people 
> at ISC already know who would be good people to bring in, if they 
> could find the funding to make that happen.
> 	So, what people like you and I can do is work to try to find ways 
> to get the necessary funding to ISC.

i mostly agree.  this mailing list was dead for a long time, and i'm happy
that it stopped being dead a week or so ago.  more community involvement
is a good thing.  more community source code submissions is a good thing.
don't sell yourselves short -- ISC needs a lot more than "nec'y funding".

however, brad's comments about "nec'y funding" are also quite accurate.

More information about the bind-workers mailing list