This is a discussion on Re: max-cache-size (was: no subject) - DNS ; At Fri, 20 Jun 2008 10:47:09 +0200, firstname.lastname@example.org wrote: > I have just "tested" the behavior of BIND 9.5 cache. > > I did a looping queryperf with 2000 internet domains ( lots of different tld ) > on a ...
At Fri, 20 Jun 2008 10:47:09 +0200,
> I have just "tested" the behavior of BIND 9.5 cache.
> I did a looping queryperf with 2000 internet domains ( lots of different tld )
> on a freshly started named during several hours, then stopped it.
> The DNS server is a Solaris 8 machine.
> Attached to this mail, you can find the graph of the CPU and memory used by the
> named process.
I can't see the attachment. I suspect the mail server doesn't like
attachments sent to the list and always strips them off...
> The result is the named process uses 32 Mb of RAM when started and goes to 64 Mb
> during the queryperf loop. 12 hours after having stopped the queryperf loop,
> named still uses 64Mb and does not clean anything in is cache even if nobody
> requests the server.
This is the expected behavior. BIND 9.5 doesn't clean cache entries
unless they are required by queries. It means the server main contain
expired entries in the cache, but as long as the total memory
footprint doesn't exceed the specified limit (i.e., max-cache-size) it
> I don't see any difference between BIND 9.4 and 9.5 even if the last one is
> using LRU cache. Maybe I am missing something.
First off, please show the value of max-cache-size. If it's larger
than 64MB, for example, the behavior you showed above is not
surprising at all.
Second, as pointed out someone else, the process uses the memory for
other purposes than cache, so it's also not surprising even if the
64MB is (a little) larger than max-cache-size.
Third, 64MB of cache is small enough for most of today's computers to
clean up even by the naive, inefficient cleaning algorithm. I suspect
you can only see meaningful difference when the server has several
hundreds MB (or even around several GB) of cache.
Internet Systems Consortium, Inc.