From owner-freebsd-questions@FreeBSD.ORG Fri Mar 31 00:24:40 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 967F216A420 for ; Fri, 31 Mar 2006 00:24:40 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 214F043D46 for ; Fri, 31 Mar 2006 00:24:39 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from localhost (monrovll-cuda1-24-53-250-148.pittpa.adelphia.net [24.53.250.148]) (AUTH: LOGIN wmoran, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Thu, 30 Mar 2006 19:24:38 -0500 id 00056426.442C76C7.0000AB4A Date: Thu, 30 Mar 2006 19:24:37 -0500 From: Bill Moran To: Kris Kennaway Message-Id: <20060330192437.043e88ff.wmoran@collaborativefusion.com> In-Reply-To: <20060330205858.GA21147@xor.obsecurity.org> References: <442B2FC6.9040001@123.com.sv> <20060330011834.GA84658@xor.obsecurity.org> <442BF0BB.8010504@123.com.sv> <20060330202145.GA17856@xor.obsecurity.org> <20060330205858.GA21147@xor.obsecurity.org> Organization: Collaborative Fusion X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mmiranda@123.com.sv, freebsd-questions@freebsd.org, usleepless@gmail.com Subject: Re: terrible performance in 6.1beta4 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 00:24:40 -0000 Kris Kennaway wrote: > On Thu, Mar 30, 2006 at 10:49:01PM +0200, usleepless@gmail.com wrote: > > Kris, > > > > > Yes, this is my impression of the problem too. Any time your process > > > is waiting on disk I/O it is going to perform terribly (on any OS - > > > disks are slow), and the way to fix this is to make sure it does as > > > little I/O as possible (by allowing everything to be cached in RAM). > > > > just for my curiosity, do you share my opinion on the fsync issue? > > Actually I seem to recall that on Linux with default settings fsync() > lies and does not actually sync data before returning, so maybe it's > worth turning off on FreeBSD too if you're comfortable with the > implications of this. If you have fsync off and the system crashes, your PostgreSQL database will probably be corrupt beyond repair. I believe the official word from the PostgreSQL folks is that fsync is safe to turn off if you've got battery-backed cache on your disk controllers. Many high-end SCSI controllers have this as an option. Alternatively, if you're just putting the database on for the first time, you can temporarily turn fsync off while you're uploading the data. If the system crashes during this, just delete and recreate the database and try again. It's not generally a good idea to run in production with fsync off, however, unless you have a battery on your controller. -- Bill Moran Potential Technologies http://www.potentialtech.com