BIND 9.3.2 on FreeBSD 6.1 out of control

[Thomas Schulz]

In article <enub7h$2v57$1 at sf1.isc.org>, patrick  <gibblertron at gmail.com> wrote:
>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 think that many if not most people do not set max_cache_size.  If you
have enough memory and have limits set high enough that they never hit,
bind will reach a high but stable memory usage after running several
days.

>Patrick
>
>On 1/7/07, Mark Andrews <Mark_Andrews at isc.org> wrote:
>>
>> > So is no one else experiencing this sudden surge in CPU usage when
>> > BIND 9 hits its max cache size?
>>
>>         When the cache hits it's max size it trigger's a cleaning
>>         pass which randomly removes 25% of the RRset's in the cache
>>         as well as cleaning those that have expired.  That will
>>         take some cpu usage.
>>
>>         At some point it would be nice to make the overmemory removal
>>         be LRU based rather than random.
>>
>>         Mark
>>
>> > On 1/3/07, patrick <gibblertron at gmail.com> wrote:
>> > > But when it reaches that limit, is there any reason why the named
>> > > process starts eating up all CPU time? The memory size, I can handle
>> > > (and control) -- it's the unexplained CPU usage that concerns me.
>> > >
>> > > This server is a master for 143 domains, and will likely take on many
>> > > more. Is there a way I can see what's in the cache? I'd just like to
>> > > get an idea of how much memory each record takes up so I can do some
>> > > math for future planning on resource requirements.
>> > >
>> > > Patrick
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>>
>
>


-- 
Tom Schulz
schulz at adi.com