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

JINMEI Tatuya / 神明達哉 jinmei at isl.rdc.toshiba.co.jp
Sun Feb 20 03:43:54 UTC 2005


>>>>> On Sun, 20 Feb 2005 02:44:29 +0100, 
>>>>> Brad Knowles <brad at stop.mail-abuse.org> said:

>> I'd first like to recommend disabling threads.  From my experiences,
>> enable-threads buys almost nothing for most OSes, unfortunately.  If
>> you can allow the configuration with 2 named processes, it should
>> provide better performance than a single BIND9 process with 2 threads.

> 	But BIND9 already has serious memory problems, and running 
> multiple copies would make that situation far, far worse.  Moreover, 
> 99% of the content between the two copies would be duplicated, and 
> you run into the problem where you need to split your incoming 
> traffic across the separate processes, and that's not always easy to 
> do.

> 	We ran into all these same problems when I set up the AOL Caching 
> Nameserver farm at AOL in '96-'97, using four DEC Alpha 4100 machines 
> with four CPUs each, 4GB of RAM, and four copies of BIND 8 running on 
> each machine, in active-active failover.  Sure, the whole cluster 
> could do something on the order of 32,000 queries per second, with 
> each copy of BIND topping out at 2000 qps, but then you come up with 
> the problem of how to distribute that load across the cluster so that 
> you really do see the throughput potential?

Perhaps I was not really clear...I didn't mean running two BIND9
processes disabling threads is a feasible long-term solution.  I just
clarified the current status of BIND9 threading and tried to make a
realistic solution for the current real problem (of someone) based on
the fact.

I must admit I jumped in some sense though.  What we should first try
is that running a *single* process of BIND9 disabling threads.  If it
can provide necessary response performance (with moderate CPU usage),
we are done.

If it cannot, we'll then need to consider running two processes of
BIND9, each of which disables threads.  Here is a tradeoff, though:
two processes should handle more queries in total, but will require
more memory.

Another problem with multiple processes is that how we can distribute
the query load to the processes, as you pointed out.  But according to
the original post, it seemed to me this seemed to be done, somehow,
with multiple BIND8 processes.  That's why I mentioned this
possibility (please, note again that I was not talking about a
generic, long-term solution).

Regarding memory consumption, yes, it can be a serious problem in this
environment.  But I believe we can reduce memory consumption in this
case, at least to some extent - see my previous message.

In any case, I don't think running a single process enabling threads
helps in this situation, since it even won't run faster (much) than
a single non-threading process.

> 	For nameservers which have any amount of authoritative function, 
> the BIND9 threading solution means that the nameserver is not blind 
> on startup, which I consider to be a huge win over BIND8 -- a 
> critical win, even.

> 	I don't think this is a feasible long-term solution.

> 	If we can't make BIND9 with threading work as well as or better 
> than multiple copies of BIND8, then we might as well go home.  IMO, 
> BIND8 can't be retired until this happens.

I'd not jump into this conclusion, since BIND9 provides other
advantages over BIND8, including views, better IPv6 support, better
dynamic update support, DNSSEC support (if you are a fun of this),
etc, etc...

But I completely agree that BIND9 should provide better performance
with threading in the middle or long term.

>> One possible reason for this is that max-cache-size did not work for
>> ADB, another memory-conscious database for caching servers, in 9.2.x.
>> I believe 9.3.x has a fix to this.

> 	Have we finally implemented an interface to Berkeley DB?

I don't know why you have this impression, but I was talking about an
internal data structure in BIND9 which maps from a host name to an IP
address and vice versa (used for contacting remote authoritative
servers).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp


More information about the bind-workers mailing list