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 7F6A29DC82D for ; Tue, 21 Mar 2006 07:03:29 -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 42283-02 for ; Tue, 21 Mar 2006 07:03:31 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from linda-1.paradise.net.nz (bm-1a.paradise.net.nz [203.96.152.180]) by postgresql.org (Postfix) with ESMTP id 6CE379DC885 for ; Tue, 21 Mar 2006 07:03:27 -0400 (AST) Received: from smtp-1.paradise.net.nz (tclsnelb1-src-1.paradise.net.nz [203.96.152.172]) by linda-1.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IWH00G395DT9R@linda-1.paradise.net.nz> for pgsql-performance@postgresql.org; Tue, 21 Mar 2006 23:03:29 +1200 (NZST) Received: from [192.168.1.11] (218-101-28-245.dsl.clear.net.nz [218.101.28.245]) by smtp-1.paradise.net.nz (Postfix) with ESMTP id B08E14D87E8; Tue, 21 Mar 2006 23:03:28 +1200 (NZST) Date: Tue, 21 Mar 2006 23:03:26 +1200 From: Mark Kirkwood Subject: Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec In-reply-to: <20060321103219.GD15742@pervasive.com> To: "Jim C. Nasby" Cc: Vivek Khera , Postgresql Performance Message-id: <441FDD7E.7050106@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051106) References: <20060317221116.GA14661@juniper.net> <8F6490E1-64E2-406B-A559-7DA8BA1EB197@khera.org> <20060321103219.GD15742@pervasive.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.172 required=5 tests=[AWL=0.172] X-Spam-Score: 0.172 X-Spam-Level: X-Archive-Number: 200603/378 X-Sequence-Number: 17815 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! Cheers Mark