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

[Attila Nagy]

On 2008.01.30. 3:28, JINMEI Tatuya / 神明達哉 wrote:
> At Tue, 29 Jan 2008 11:40:39 +0100,
> Attila Nagy <bra at fsn.hu> wrote:
>
>   
>>>> Without threading I don't see this effect, the memory usage stops at a 
>>>> sane limit and it's size can be affected by setting the max-cache-size 
>>>> option.
>>>>
>>>> I don't think you would gain anything usable with that, am I right?
>>>>         
>>> Right.  Can you try a simpler patch that focuses on the memory usage
>>> status and works with threads?  If so, I'll write one and send it to
>>> you.
>>>   
>>>       
>> Of course. The machines are diskless, so writing larger log files 
>> directly is not an easy task. (syslog is ok)
>>     
>
> Okay, please use the attached patch (applicable to 9.5.0b1, and also
> to 9.5.0b2 when it's published).  Build it with:
> % STD_CDEFINES='-DLRU_DEBUG2=2' ./configure --enable-threads
> (or set STD_CDEFINES using setenv if you use a csh variant)
>   
Will try, thanks.
>> ps: I have an other problem. I've recently switched from a last year 
>> 6-STABLE to 7-STABLE and got pretty bad results on the same machine with 
>> the same bind (9.4).
>> The graphs are here:
>> http://picasaweb.google.com/nagy.attila/20080129Fbsd6vs7Bind
>>
>> The interesting part (from when the comments are valid) starts at around 
>> the half of the picture. You can see that on FreeBSD 6, the CPU load is 
>> pretty much good, but on 7, both the userspace and the kernelspace 
>> activity grows significantly.
>>     
>
> I have no idea about why this happened at the moment.  Do both server
> handle the same level of query rate?  (I'm also curious what happened
> in the first half of the graphs for both cases).
>   
Exactly the same (a per packet load balancer is in front of them). Even 
the machines are the same. I've replaced the pictures, the previous ones 
included some unintended reboot-n-try stuff.
>   
>> I've used libthr on 6, and it is the default on 7 too. bind is threaded.
>> I use ISC_INTERNAL_MALLOC, but the effect is the same without it.
>>     
>
> This shouldn't matter because ISC_INTERNAL_MALLOC is enabled by
> default as of 9.4.
>   
Ouch, I didn't know this. Thanks for the clarification.