Date: Thu, 03 Apr 2008 17:22:38 +0200 From: Attila Nagy <bra@fsn.hu> To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= <Jinmei_Tatuya@isc.org> Cc: freebsd-performance@freebsd.org, bind-users@isc.org Subject: Re: max-cache-size doesn't work with 9.5.0b1 Message-ID: <47F4F63E.80703@fsn.hu> In-Reply-To: <m2pruse24g.wl%Jinmei_Tatuya@isc.org> References: <475B0F3E.5070100@fsn.hu> <m2lk6g71bc.wl%Jinmei_Tatuya@isc.org> <479DFE74.8030004@fsn.hu> <m2k5ltke09.wl%Jinmei_Tatuya@isc.org> <479F02A7.9020607@fsn.hu> <m24pcwt5b7.wl%Jinmei_Tatuya@isc.org> <47A614E9.4030501@fsn.hu> <m2wspkpl7r.wl%Jinmei_Tatuya@isc.org> <47A77A13.6010802@fsn.hu> <m2zlueohxk.wl%Jinmei_Tatuya@isc.org> <47B1D2F4.5070304@fsn.hu> <m2tzkexdo7.wl%Jinmei_Tatuya@isc.org> <47B2DD62.6020507@fsn.hu> <m2abm4y4by.wl%Jinmei_Tatuya@isc.org> <47BAE0B3.4090004@fsn.hu> <m2pruse24g.wl%Jinmei_Tatuya@isc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@fsn.hu
Free Software Network (FSN.HU) phone: +3630 306 6758
http://www.fsn.hu/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47F4F63E.80703>