From owner-freebsd-performance@FreeBSD.ORG Thu Sep 4 15:07:24 2003 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86FCD16A4BF for ; Thu, 4 Sep 2003 15:07:24 -0700 (PDT) Received: from flake.decibel.org (flake.decibel.org [66.143.173.58]) by mx1.FreeBSD.org (Postfix) with SMTP id 355A943FAF for ; Thu, 4 Sep 2003 15:07:21 -0700 (PDT) (envelope-from decibel@decibel.org) Received: (qmail 33822 invoked by uid 1001); 4 Sep 2003 22:07:10 -0000 Date: Thu, 4 Sep 2003 17:07:09 -0500 From: "Jim C. Nasby" To: freebsd-performance@FreeBSD.ORG Message-ID: <20030904220709.GR37152@nasby.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.8-RELEASE-p3 i386 X-Distributed: Join the Effort! http://www.distributed.net Subject: Best disk caching method (and PGSQL performance) X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2003 22:07:24 -0000 After reading the thread at http://www.freebsd.org/cgi/getmsg.cgi?fetch=25060+34014+/usr/local/www/db/text/2003/freebsd-performance/20030727.freebsd-performance and the post at http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&selm=199907290910.CAA06665%40implode.root.com I'm a bit confused about how best to get FBSD to cache disk I/O on a PostgreSQL server. Reading the VM article at http://www.daemonnews.org/200001/freebsd_vm.html has certainly made things a bit clearer, but I want to make sure I'm understanding things before I go tweaking stuff. The inactive queue is only comprised of pages that have been read in as mapped memory, correct? I believe PGSQL does not make use of memory-mapped I/O, so does that mean that the only place data reads are being cached is in the buffer pool? (Note that this contradicts the google link). If that's indeed the case, then it seems like the only way to get a decent amount of data caching is by increasing the buffer size (which apparently means increasing kern.nbuf, which also means increasing KVA_PAGES (though I'm not at all sure about this). If this isn't the case, why have the buffer pool at all? Why not just leave buffered disk pages in the inactive or cache queues? On another note, does anyone know for certain that PGSQL on FBSD is fsyncing only the WAL? I'm seeing a pretty large amount of activity on my primary partition and I'm wondering if it's fsyncing everything. Also, has anyone played with the other fsync options? -- Jim C. Nasby, Database Consultant jim@nasby.net Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"