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 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@fsn.hu
Free Software Network (FSN.HU) phone: +3630 306 6758
http://www.fsn.hu/