max-cache-size doesn't work with 9.5.0b1

[JINMEI Tatuya / 神明達哉]

At Sun, 03 Feb 2008 20:24:25 +0100,
Attila Nagy <bra at fsn.hu> wrote:

> Yes, if bind was built with threads, the memory usage always grew behind 
> max-cache-size very quickly.
> 
> Here is the log:
> http://people.fsn.hu/~bra/freebsd/bind950-memory-20080203/bind950b1
> the memory usage (RSS, reported by top) in megabytes:
> 19:10:37 466
> 19:11:20 522
> 19:11:53 566
> 19:13:06 666
> 19:14:17 766
> 
> max-cache-size was set to 64M.

Hmm.  According to the log message, named seems to control the cache
memory pretty well so that it doesn't exceed max-cache-size.  So, the
memory hog should be somewhere else.

One obvious explanation is memory leak, of course.  If it occurs
within named, you should be able to find it by stopping the daemon
(memory leak will trigger assertion failure).

Another possible scenario is that you're being hit by known memory
leak in the built-in statistics HTTP server (unfortunately, this isn't
caught by assertion).  If you've enabled the feature and are
retrieving statistics via HTTP at a very high rate, your server will
possibly eat memory avariciously.  I actually suspect that this is NOT
the likely cause in this case, from the very rapid growth you showed,
but if you enable the built-in HTTP server, could you turn it off and
try again?  BTW, this leak will be fixed in 9.5.0b2.

Finally, at the risk of pointing a finger at someone else who's
innocent, is it possible that there's leak in FreeBSD's thread
library?  For example, busy BIND9 caching servers frequently create
and destroy mutex locks; if the thread library fails to cleanly free
memory for mutex's, the server memory will grow rapidly.

p.s. I'm afraid the patch Mark provided in his response won't solve
this particular problem from the information we've got so far.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.