X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id D9663D6D71 for ; Tue, 11 Oct 2005 14:24:02 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 90094-01 for ; Tue, 11 Oct 2005 17:23:59 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by svr1.postgresql.org (Postfix) with ESMTP id B11CBD6F01 for ; Tue, 11 Oct 2005 14:23:58 -0300 (ADT) Received: by wproxy.gmail.com with SMTP id 71so227590wra for ; Tue, 11 Oct 2005 10:23:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J8v7z+Ie2XncbYsGdS1FlURpOjGNy+BsCszZRMx1Pfh5a88/NAvfltnfOMOGX1nc+9/AkLiPfAKHSB7xG8XmNMfZp0XsfkKhXI4Mjx9j6r5W7NW8lzXwyhWHoqBITiwRKhMwXII2wm4nztJmYNL71wBYA/gq45KiKuZfMzaF48Y= Received: by 10.54.69.10 with SMTP id r10mr3646364wra; Tue, 11 Oct 2005 10:23:59 -0700 (PDT) Received: by 10.54.144.4 with HTTP; Tue, 11 Oct 2005 10:23:59 -0700 (PDT) Message-ID: Date: Tue, 11 Oct 2005 19:23:59 +0200 From: Claus Guttesen To: Sven Willenberger Subject: Re: effective cache size on FreeBSD (WAS: Performance on SUSE w/ Cc: Jon Brisbin , pgsql-performance@postgresql.org In-Reply-To: <1129043064.1975.22.camel@lanshark.dmv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1129043064.1975.22.camel@lanshark.dmv.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.024 required=5 tests=[RCVD_BY_IP=0.024] X-Spam-Level: X-Archive-Number: 200510/201 X-Sequence-Number: 14969 > > > Apparently this formula is no longer relevant on the FreeBSD systems = as > > > it can cache up to almost all the available RAM. With 4GB of RAM, one > > > could specify most of the RAM as being available for caching, assumin= g > > > that nothing but PostgreSQL runs on the server -- certainly 1/2 the R= AM > > > would be a reasonable value to tell the planner. > > > > > > (This was verified by using dd: > > > dd if=3D/dev/zero of=3D/usr/local/pgsql/iotest bs=3D128k count=3D1638= 4 to create > > > a 2G file then > > > dd if=3D/usr/local/pgsql/iotest of=3D/dev/null > > > > > > If you run systat -vmstat 2 you will see 0% diskaccess during the rea= d > > > of the 2G file indicating that it has, in fact, been cached) > > > > Thank you for your reply. Does this apply to FreeBSD 5.4 or 6.0 on > > amd64 (or both)? > > > > Not sure about 6.0 (but I don't know why it would change) but definitely > on 5.4 amd64 (and I would imagine i386 as well). Works on FreeBSD 6.0 RC1 as well. Tried using count=3D4096 on a 1 GB ram box. Same behaviour as you describe above. regards Claus