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

[Attila Nagy]

Sorry again for the long delay, I've got other work to do, and our 9.4 
servers work fine (at least on FreeBSD 6, though, see the other 
-performance- problem)...

On 02/20/08 04:30, JINMEI Tatuya / 神明達哉 wrote:
> At Tue, 19 Feb 2008 14:59:15 +0100,
> Attila Nagy <bra at fsn.hu> wrote:
>
>   
>>> Okay, then please try this patch with '-n 1' (note: this patch doesn't
>>> contain the memory statistics hack via the HTTP interface, but I don't
>>> we don't need it for this test).
>>>       
>
> [...]
>
>   
>> (max-cache-size still 32M)
>>     
>
> Hmm, then the mutex locks dynamically generated are also irrelevant.
>
> I've also tried to reproduce the problem in a similar environment
> (BIND 9.5.0b1 with threads on FreeBSD 7.0RC1/AMD64, cache-only
> configuration, using a real query sample), unsuccessfully.  One
> significant difference is that I disabled SMP in the kernel (it was
> very unstable with the SMP support for some unknown reason), but I
> doubt this is the key for the difference of the named behavior.
>   
I don't know why am I the only one to see this.

> BTW, is this reproduceable on FreeBSD 6.x?  If so, then I'd like to
> see what happens if you specify some small value of datasize
> (e.g. 512MB) and have named abort when malloc() fails with the "X"
> _malloc_options.  (This option doesn't seem to work for FreeBSD 7.x,
> at least at the moment).
>   
Yes, it's the same, even when there is a different (libpthreads, KSE) 
threading library is in use.
I've recompiled named with the following in main():
./work/bind-9.5.0b2/bin/named/main.c:   _malloc_options="X";

And set cache-size to 32MB.

At:
21664 bind        4  20    0   819M   819M kserel 0   5:32  0.00% named.950
I pressed a CTRL-C:
mem.c:1114: REQUIRE((((ctx) != ((void *)0)) && (((const isc__magic_t 
*)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C')))))) 
failed.

> Some other questions:
> - can we see your named.conf?  If you specify non-default
>   configuration options, that might be the reason for, or related to,
>   this problem.
>   
Of course (see at the end).

> - does your named produce lot of log messages?  If so, it might also
>   be a reason (simply because it relies on standard libraries).
>   
grep named ns20080403.log | wc -l
1930006
For today (17 hours and 18 minutes of logs).
Is this a lot?

Config (normally max-cache-size is about 2400M):
-hmm I haven't tried to change cleaning-interval, it was needed because 
the default cache housekeeping effectively stopped the ns during the 
cleanup-

options {
        directory "/etc/bind";
        tcp-clients 256;
        recursive-clients 8192;
        max-cache-size 32M;
        minimal-responses yes;
        pid-file "/var/run/named.pid";
        cleaning-interval 15;
        allow-query-cache { any; };
        allow-query { any; };
        allow-recursion { any; };
};

controls {
        inet * port 953
                allow { } keys { "rndc-key"; };
};

key "rndc-key" {
        algorithm hmac-md5;
        secret
};

logging {
    channel syslog-ng {
        syslog local5;
        severity info;
        print-category yes;
        print-severity yes;
        };
    category default            { syslog-ng; };
    category config             { syslog-ng; };
    category xfer-in            { syslog-ng; };
    category xfer-out           { syslog-ng; };
    category notify             { syslog-ng; };
    category security           { syslog-ng; };
    category update             { syslog-ng; };
    category lame-servers       { syslog-ng; };
    category update-security    { syslog-ng; };
};

zone "10.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "16.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "17.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "18.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "19.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "20.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "21.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "22.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "23.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "24.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "25.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "26.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "27.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "28.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "29.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "30.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "31.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; };
zone "168.192.in-addr.arpa" in { type master; file "db/db.rfc1918"; };


-- 
Attila Nagy                                   e-mail: Attila.Nagy at fsn.hu
Free Software Network (FSN.HU)                 phone: +3630 306 6758
http://www.fsn.hu/