>>>>> On Mon, 8 Jan 2007 12:51:05 -0800,
>>>>> patrick said:


> Seems to me like this shouldn't take all that long though, should it?
> What's happening with me is that when it hits the max_cache_size, it
> consumes the CPU indefinitely. The only way to get it to settle down
> is to kill the process and restart it.


> Out of curiosity, do most people set max_cache_size? If not, how is
> BIND not indefinitely growing? If they do, how big is it usually set?
> I'm getting the impression that most people are not experiencing the
> same problems as me, but I have no idea what I could be doing wrong
> because I'm not sure how everyone else has configured their servers.
> My configuration file hasn't changed too much since upgrading from
> BIND 8.


I've often heard this type of symptom, especially on FreeBSD. One
common cause is that BIND9's cache cleaning (prior to 9.4) relies on
system's malloc()/free() routines, which could run inefficiently on
FreeBSD (I'm not really sure if it's still the case for 6.1, but it
was at least for some 4.X versions); and one common workaround is to
enable BIND9's internal memory allocator by rebuilding BIND9 with:

% ./configure STD_CDEFINES='-DISC_MEM_USE_INTERNAL_MALLOC=1'

This should be very effectively particularly for the case of cache
cleaning because it will most likely recycle pre-allocated memory
fragments without involving any system calls or possible-inefficient
standard libraries.

Notes:
- enabling the internal allocator may cause another performance
problem if you also enable threads on a multi-processor machine
(although it wouldn't matter much for FreeBSD because FreeBSD's
thread support is not really friendly with BIND9 wrt performance -
at least before 7.0)

- BIND 9.4 enables the internal allocator by default with removing the
possible bottlenecks when using it with threads (and it works well
for FreeBSD threads). So if you want to enable threads on a
multi-processor server, you may want to try 9.4; however, 9.4's
better support for threads will require a bit more memory footprint,
which is another tradeoff issue.

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