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 02:02:18 UTC 2005
>>>>> On Sun, 20 Feb 2005 02:14:31 +0100,
>>>>> Stefan Schmidt <zaphodb--bind at zaphods.net> 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.
> This i can do - adapting the bind8 config files should do the trick, but i
> will have to impose max memory for the two processes to roughly 450MB via
> How about using NPTL with bind9 btw.?
I'm not sure, but I don't think it helps much (if it does anyway).
>> 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
> I.e. throwing hardware at a problem - this is not the kind of solution i like
I know, so I was reluctant to say that, but "not the best solution"
can still be better than nothing...
> Why is bind9 using twice the memory bind8 does - are there serious
> changes to the way the RRs are cached or is it that bind9 needs to keep the
> data twice for some internal reason like views?
Of course, there are serious changes on every part of the software;
those two are completely different beasts. Of course, again, just
being different does not necessarily mean it requires more memory - I
don't know much about the caching server case, but from my experiences
on authoritative servers, the required memory for RRs on BIND9 is not
that larger. So I guess there may be some characteristics specific to
your configuration/environment or to the caching case in general. For
- the BIND9 caching server needs to maintain additional space for ADB.
It may require more memory than the similar notion of BIND8 (I don't
have any data source on this)
- the algorithm of periodical cleaning on cached entries *may* matter.
(again, I don't know the difference between BIND8 and BIND9 on this
- regarding views, each view maintains its own caching entries. So,
if you happen to have two (or more) views equally receiving
recursive queries, growing the caches, while the cached data can
actually be shared, then you'd end up with more memory consumption
> I will have a look at how bind9.2 behaves if i set max-cache-size to 900M. I
> suspected the cache purges anyways.
>> > 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.
> I will first try bind9.2 non-threaded with max-cache-size lesser than the
> ulimit and then have a look at how bind9.3 behaves on this.
If you go with disabling threads, you may also want to enable
"internal memory allocation". (I hear that) it should use memory more
efficiently (and can make the server faster) but is disabled by
default due to response-performance reasons in the threaded case. You
can enable this feature by adding the following line
#define ISC_MEM_USE_INTERNAL_MALLOC 1
just before the following part of bind9/lib/isc/mem.c:
#define ISC_MEM_USE_INTERNAL_MALLOC 0
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei at isl.rdc.toshiba.co.jp
More information about the bind-workers