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
Sat Feb 19 23:58:24 UTC 2005


>>>>> On Thu, 17 Feb 2005 16:28:57 +0100, 
>>>>> Stefan Schmidt <zaphodb--bind at zaphods.net> said:

>> 1808.	[bug]		zone.c:notify_zone() contained a race condition,
>>		zone-> db could change underneath it.  [RT #13511]
> As i have it this change would not be something that could trigger high user
> cpu usage when running threaded, right?

This bug only matters for authoritative servers, so it should most
likely be irrelevant to your problem.

> On my resolver-Cluster i am mainly running current bind8 versions but i
> thought i would give bind9 a try again as you are clearly planning on ending
> security bugfix support for it in the long term.
> Please see attached image for cpu usage. The query-load was stable and
> underlying a natural (dsl) usage curve throughout the whole time.
> Sustained peak query rate was 600-700 qps, minimum 130 qps. Graphs on reque=
> st.
> I only switched bind versions; kernel version, uptime, swapping behaviour
> was/has not changed in any way.
> The image shows cpu usage change when i switched the machine from _two_!
> bind 8.4.6-REL processes to _one_ bind 9.2.5beta2-threaded.
> The machine is running Linux 2.6.11-rc2 debian/unstable with libc6-i686 on a
> Compaq Proliant DL360 G1 (i.e. 2xPIII 800MHz 1GB RAM).

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.

Secondly, according to your memory usage and configuration (i.e.,
max-cache-size=700M, 623m used), it looks like named reaches the
high-water mark for the specified maximum, and tries to purge some
cache entries.  If this periodically happens, it may be the reason for
the high CPU usage.  So, if possible, it might help if you can add
more memory which can afford the typical use case under the high-water
level.

BTW:
> top states. I have set max-cache-size 700M; there but previous bind9
> experiments show that it does not really care about when it breaches this
> limit. On Linux that is capability module loaded. Sorry ISC.

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.

					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