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 21:50:36 UTC 2005

>>>>> On Sun, 20 Feb 2005 17:33:22 +0100, 
>>>>> Brad Knowles <brad at stop.mail-abuse.org> said:

>> 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.

> 	Okay, fair enough.  However, the OP was testing out BIND9.  He 
> wasn't in a situation where he was absolutely required to run BIND9, 
> and therefore would need whatever tips or hacks that people can offer 
> to try to get something semi-reasonably working.

(I don't know who is OP, but) I know, and I thought I had tried to
provide information based on this fact.

> 	In the case of the OP, he's pointing out issues that he's running 
> into with BIND9 when trying to use it pretty much the same way as he 
> is using BIND8 on all of his other machines, and this is a clear 
> indicator of an issue that needs to be addressed within the code.

Again, yes, and I already agreed that BIND9 should eventually provide
better performance with threading.  I don't think it contradicts
suggesting turn threading off for the moment as an operational nit.

>> 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 you had said "moderate CPU usage and moderate memory usage", I 
> might have bought that argument, even considering that the threading 
> model is one of the big advantages that BIND9 is supposed to have 
> over BIND8.  But throwing out threading and using excessive memory is 
> not an adequate solution for this testing, even if we can get the CPU 
> utilization down.

I already admitted that I had known adding more memory is not the best
solution, but I provided supplemental comments regarding memory
consumption.  Perhaps I was not really clear again, so let me rephrase
that once more:

1. my first suggestion is to disable threading, to enable internal
   memory allocator, and to run a single process of BIND9.  I thought
   this can provide "moderate memory usage" (and moderate CPU usage).
   If the resulting performance is acceptable, we are done.

2. if the resulting performance is not acceptable, then my next
   suggestion is to run 2 processes of BIND9 with the above
   configuration.  I thought this should run with moderate memory
   usage, and would probably provide acceptable performance with
   acceptable CPU usage in total.

3. if the result of step 2 is still not acceptable, we'll perhaps need
   to go back to BIND8.

4. In any case, I'd not suggest sticking to threaded version of BIND9
   in this environment, because
   + the performance gain should be almost zero, even comparing to a
     single process of non-threaded BIND9.
   + we (probably) cannot reduce memory usage by enabling internal
     memory allocator in this case due to the performance penalty of
     this feature with threads

>> 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.

> 	Threading is not about speed, at least not on a single CPU 
> system.  Threading in BIND9 is about the other things it can do for 
> you, while providing roughly comparable straight-out performance.

I would first like to note once again that I was talking about one
particular case where we have two CPUs.

Secondly, I know "threading is not about speed, at least not on a
single CPU system".  But could you be more specific on what threaded
BIND9 can provide on a single CPU?  In my understanding, BIND9
carefully decomposes its tasks into small chunks and avoids using
blocking APIs so that every single task (in BIND9) will not make
others wait for a long period.  In that sense, we can even say that
non-threaded version of BIND9 implements threading internally.  So I
cannot see any benefit of running threaded version of BIND9 on a
single CPU system.

> 	Now, when you talk about SMP machines, threading in BIND9 should 
> definitely provide better performance than a single instance of BIND8 
> on the same machine, and it should be able to provide roughly 
> comparable performance to a number of BIND8 instances equal to the 
> number of CPUs in the system.

Wait a minute...are you talking about the current performance of
threaded BIND9, or about what threaded BIND9 should be in the future?

Regarding the former, I admit my experiences in this area are limited,
but from my experiences with {FreeBSD, Linux, Solaris, True64} on
{Xeon, opteron, sparc, alpha}, I've almost never seen the case where
threaded BIND9 provide better performance than a single process of

If you meant the latter, I agree at least on the first point.

					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