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

[Attila Nagy]

On 2008.02.04. 20:36, JINMEI Tatuya / 神明達哉 wrote:
> 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.
>   
I didn't even look after how could I enable the built-in HTTP server, so 
if it's not on by default, I haven't had it.

> 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.
>   
Bind 9.4.2 works fine on the same machine (threaded), if that counts.

> 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.
>   
I will try it nevertheless.