From owner-freebsd-performance@FreeBSD.ORG Mon Jul 21 13:16:49 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 322B837B401; Mon, 21 Jul 2003 13:16:49 -0700 (PDT) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7439543F85; Mon, 21 Jul 2003 13:16:46 -0700 (PDT) (envelope-from sean@nxad.com) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id 8EB99210FF; Mon, 21 Jul 2003 13:16:45 -0700 (PDT) Date: Mon, 21 Jul 2003 13:16:45 -0700 From: Sean Chittenden To: "Jim C. Nasby" Message-ID: <20030721201645.GD61464@perrin.int.nxad.com> References: <20030721043501.F14379-100000@walter> <20030721192645.GB61464@perrin.int.nxad.com> <20030721194519.GE55392@nasby.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030721194519.GE55392@nasby.net> X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 3849 3760 1AFE 7B17 11A0 83A6 DD99 E31F BC84 B341 X-Web-Homepage: http://sean.chittenden.org/ User-Agent: Mutt/1.5.4i cc: freebsd-database@freebsd.org cc: freebsd-performance@freebsd.org cc: Jason Stone Subject: Re: Tuning for PostGreSQL Database 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: Mon, 21 Jul 2003 20:16:49 -0000 > > > > Softupdates on, async off. Softupdates is just a better > > > > async. > > > > > > postgresql fsync's all its files before returning from a commit > > > in order to ensure durability, right? Does softupdates > > > interfere with the functioning of sync(2)/fsync(2)? > > > > It can, yes, but that's the risk of soft updates. From tuning(7): > > > > Softupdates drastically improves meta-data performance, > > mainly file creation and deletion. We recommend enabling > > softupdates on most file systems; however, there are two > > limitations to softupdates that you should be aware of when > > determining whether to use it on a file system. First, > > softupdates guarantees file system consistency in the case of > > a crash but could very easily be several seconds (even a > > minute!) behind on pending write to the physical disk. If > > you crash you may lose more work than otherwise. Secondly, > > softupdates delays the freeing of file system blocks. If you > > have a file system (such as the root file system) which is > > close to full, doing a major update of it, e.g. ``make > > installworld'', can run it out of space and cause the update > > to fail. For this reason, softupdates will not be enabled on > > the root file system during a typical install. > > So are you saying that softupdates on whatever partition contains > the database transaction logs is dangerous? Well, think about it. What happens when you pull the plug while the OS is sitting on a pile of data that it's waiting to flush to disk? The problem isn't so much with the WAL logs, so much as it is with the actual files that contain the databases/table's data. Any kind of volatle backed buffer increases the danger of data loss. Good solution for these concerns? Get a UPS. > Luckily, the metadata for these files is changed very infrequently > (normally), so this shouldn't prove to be much of a performance > impact. Correct. -sc -- Sean Chittenden