At Sun, 03 Feb 2008 20:24:25 +0100, Attila Nagy <[EMAIL PROTECTED]> 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. _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
