X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 25A5D9DC981 for ; Tue, 21 Mar 2006 07:47:15 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 50606-05 for ; Tue, 21 Mar 2006 07:47:17 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id C3E219DC8DB for ; Tue, 21 Mar 2006 07:47:11 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id AF57B56427; Tue, 21 Mar 2006 05:46:59 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Tue, 21 Mar 2006 05:46:59 -0600 Date: Tue, 21 Mar 2006 05:46:59 -0600 From: "Jim C. Nasby" To: Mark Kirkwood Cc: Vivek Khera , Postgresql Performance Subject: Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec Message-ID: <20060321114658.GK15742@pervasive.com> References: <20060317221116.GA14661@juniper.net> <8F6490E1-64E2-406B-A559-7DA8BA1EB197@khera.org> <20060321103219.GD15742@pervasive.com> <441FDD7E.7050106@paradise.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <441FDD7E.7050106@paradise.net.nz> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060321:markir@paradise.net.nz::Ly3fCyZqwFYrWQZs:000000000000000 0000000000000000000000001Svw X-Hashcash: 1:20:060321:vivek@khera.org::ZFM8/m4bc2PzxPMO:001ngT X-Hashcash: 1:20:060321:pgsql-performance@postgresql.org::9rQQoby8A23oc+oR:00000 0000000000000000000000004vkx X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.108 required=5 tests=[AWL=0.108] X-Spam-Score: 0.108 X-Spam-Level: X-Archive-Number: 200603/383 X-Sequence-Number: 17820 On Tue, Mar 21, 2006 at 11:03:26PM +1200, Mark Kirkwood wrote: > Jim C. Nasby wrote: > >On Mon, Mar 20, 2006 at 02:15:22PM -0500, Vivek Khera wrote: > > > >>I think FreeBSD has a hard upper limit on the total ram it will use > >>for disk cache. I haven't been able to get reliable, irrefutable, > >>answers about it, though. > > > > > >It does not. Any memory in the inactive queue is effectively your 'disk > >cache'. Pages start out in the active queue, and if they aren't used > >fairly frequently they will move into the inactive queue. From there > >they will be moved to the cache queue, but only if the cache queue falls > >below a certain threshold, because in order to go into the cache queue > >the page must be marked clean, possibly incurring a write to disk. AFAIK > >pages only go into the free queue if they have been completely released > >by all objects that were referencing them, so it's theoretically > >posisble for that queue to go to 0. > > Exactly. > > The so-called limit (controllable via various sysctl's) is on the amount > of memory used for kvm mapped pages, not cached pages, i.e - its a > subset of the cached pages that are set up for immediate access (the > others require merely to be shifted from the 'Inactive' queue to this > one before they can be operated on - a relatively cheap operation). > > So its really all about accounting, in a sense - whether pages end up in > the 'Buf' or 'Inactive' queue, they are still cached! So what's the difference between Buf and Active then? Just that active means it's a code page, or that it's been directly mapped into a processes memory (perhaps via mmap)? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461