From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 21:59:54 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 761FE16A421 for ; Mon, 28 Jan 2008 21:59:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 2E97113C4CE for ; Mon, 28 Jan 2008 21:59:53 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 22325 invoked by uid 399); 28 Jan 2008 21:59:53 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 28 Jan 2008 21:59:53 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <479E5057.6000309@FreeBSD.org> Date: Mon, 28 Jan 2008 13:59:51 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.9 (X11/20080126) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <86k5lv1l84.fsf@ds4.des.no> In-Reply-To: <86k5lv1l84.fsf@ds4.des.no> X-Enigmail-Version: 0.95.5 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: hackers@freebsd.org Subject: Re: 'periodic daily' memory usage X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 21:59:54 -0000 Dag-Erling Smørgrav wrote: > The solution I found that did work was to eliminate the loop over > $MP and use 'find -s $MP ...' instead, which eliminates the need > for sort. This reduces the memory requirement for 100.checksetuid > by, oh, 80% or so, and greatly simplifies the logic. Why don't you post that diff? Sounds like a good idea to me. > Note that 'find -s' and find | sort may not produce the same > output, but this only means you'll get an ugly diff the first time > you run the new script - it won't cause any trouble later. > > An entirely different issue is why named uses so much memory... It's a feature. :) If you're using it to resolve stuff out in the wild, it's caching the answers to questions it has been asked (plus whatever additional, authoritative information that was sent by the remote name server). If you artificially reduce the size of the cache, it will result in more network traffic, assuming it gets asked the same question again. If you have a situation where you have applications that ask a lot of questions once, or just a few times in quick succession (mail farms often fit this profile) then reducing the cache size probably won't hurt too much. If you have an environment where your users ask a lot of different questions, but keep asking them, reducing the cache is just going to shift the load elsewhere. One thing you can do is reduce the cleaning interval, since that will flush out the data that is past its TTL that much faster. This works particularly well for the first scenario described above. > does anybody know of a way to specify how much memory named may use > for its cache? You'll want to use BIND 9.4.2 for that if you want to do it, and take a look at the ARM manual to get the right combination of options. I'd tell you if I knew, but I never limit the cache on my name servers. :) BTW, I think you mentioned that named had grown to 24M or so, FYI that is actually a very small process size. My very lightly loaded resolver for my home network is at 23M, with hardly any cache at all. If I thought there was a good alternative resolver I'd recommend one, but IMO BIND is it right now. There are a couple others in development right now, but they are not yet ready for prime time (again, IMO). hth, Doug -- This .signature sanitized for your protection