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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
Free Software Network (FSN.HU) phone: +3630 306 6758
http://www.fsn.hu/
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
