From owner-freebsd-performance@FreeBSD.ORG Thu Apr 3 15:22:49 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 368C81065673 for ; Thu, 3 Apr 2008 15:22:49 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id B22F88FC2D for ; Thu, 3 Apr 2008 15:22:48 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from japan.t-online.private (people [192.168.2.4]) by people.fsn.hu (Postfix) with ESMTP id 9DAABAEC18; Thu, 3 Apr 2008 17:22:38 +0200 (CEST) Message-ID: <47F4F63E.80703@fsn.hu> Date: Thu, 03 Apr 2008 17:22:38 +0200 From: Attila Nagy User-Agent: Thunderbird 2.0.0.12 (X11/20080326) MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> <47BAE0B3.4090004@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-performance@freebsd.org, bind-users@isc.org Subject: Re: max-cache-size doesn't work with 9.5.0b1 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2008 15:22:49 -0000 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/