Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 362F664FC2D for ; Thu, 6 Nov 2008 11:57:33 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 76239-09 for ; Thu, 6 Nov 2008 11:57:32 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.178]) by mail.postgresql.org (Postfix) with ESMTP id 3897864FD85 for ; Thu, 6 Nov 2008 11:57:31 -0400 (AST) Received: by el-out-1112.google.com with SMTP id p32so337909elf.10 for ; Thu, 06 Nov 2008 07:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=OblYi/c/uffszzvsawL41o5xZF5iXkt8ENnSjR4c5iE=; b=g9lQAcUDJG7naj161+Lcp/sYgz+CPyvOD7qyyZEid28Dlu4emCTXK5nWtoLNa3vC2B zqOrYVZytEYtcwsUGKLPoQQzLTXSz4TkY/5iayX+PjVgtAQch6d8G63DIYtm4KlagH4j dwykY+x3WHh2C3Epozv+EXPpPrG3FV84P8iu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SSFpV7QJnGa9mscR31dQPEN097ZiXCYpAbxfnhm8dUEAz/U3iEgCtaA7Km3TYyCv0s Dx+vAFZW3flyuXqcuifBGA/zZTiudStvL4UMhKFXyHT/XSr54GaWAAOVZkoHFG/td3iz LIfS4or/2EAfhojYMPo9VhoC9MFNufmmC+fM0= Received: by 10.151.79.6 with SMTP id g6mr1605533ybl.18.1225986447161; Thu, 06 Nov 2008 07:47:27 -0800 (PST) Received: by 10.150.211.9 with HTTP; Thu, 6 Nov 2008 07:47:27 -0800 (PST) Message-ID: <72dbd3150811060747u7f3c2aadv3c6658d285d74455@mail.gmail.com> Date: Thu, 6 Nov 2008 07:47:27 -0800 From: "David Rees" To: "Peter Schuller" , pgsql-performance@postgresql.org Subject: Re: Occasional Slow Commit In-Reply-To: <20081106102147.GB70379@hyperion.scode.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <72dbd3150810271723w57859013v9c4e3718ae86fba@mail.gmail.com> <72dbd3150810291530q7a95da64j2c39354de9ad91d1@mail.gmail.com> <72dbd3150810311714s51639bc3kfdbe03a7b51bc55c@mail.gmail.com> <72dbd3150811051925n50ead40cn30354990ebb8bfb6@mail.gmail.com> <20081106102147.GB70379@hyperion.scode.org> X-Archive-Number: 200811/27 X-Sequence-Number: 31758 On Thu, Nov 6, 2008 at 2:21 AM, Peter Schuller wrote: >> I also found that my write cache was set to WriteThrough instead of >> WriteBack, defeating the purpose of having a BBU and that my secondary >> server apparently doesn't have a BBU on it. :-( > > Note also that several RAID controllers will periodically drop the > write-back mode during battery capacity tests. If you care about > consistently/deterministically having full performance (with > white-backed battery protected caching), you probably want to confirm > your controller behavior here. > > (I've seen this on at least LSI based controllers in Dell 2950:s, and > also on some 3wares.) I can confirm that this is the case by reviewing the logs stored on the MegaRAID controller that have a BBU and had WriteBack configured. The controller also lets you know (using the MegaCli utility) what setting is configured, and what setting is in effect. In the case of the machines without a BBU on them, they are configured to be in WriteBack, but are actually running in WriteThrough. -Dave