BIND 9.3.2 on FreeBSD 6.1 out of control

patrick gibblertron at gmail.com
Mon Jan 8 20:51:05 UTC 2007


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.

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
>



More information about the bind-users mailing list