Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id B9EE8650446 for ; Wed, 5 Nov 2008 23:25: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 34230-10 for ; Wed, 5 Nov 2008 23:25:32 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mail.postgresql.org (Postfix) with ESMTP id 1CC11650442 for ; Wed, 5 Nov 2008 23:25:32 -0400 (AST) Received: by yw-out-2324.google.com with SMTP id 3so189179ywj.73 for ; Wed, 05 Nov 2008 19:25:31 -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=iP/HL44a7PgQl3m3v4upO2QzpMWzs/GDoPdFDQXR2k4=; b=J34pv8zeh3YzAIoutwY36EXK/pUFSxXm5O8ODBTcT7zvPV5uhHJ1vpTQILunpqMqUk NAvdBYEva88XuC+2ClvlLBOp1hvTdVQtfQnAbNyYWYw9nkmapnuvRbS/9+pKqG9tZ/3B 9xhVsfVOws7S3U1+jLc1ht8SuxKWGiq2d/Fbo= 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=UDO8mMG2PuiuL9DXeBwlDW6OH3xC4u0S4eW/yl6FCZ5frV4FHy7NRL5AWC1SwZUldZ dXpwiK0vgTmRuSZ4G3vNQwhTkiyj4IfubszkxZs8DHCCckvHdGnktgI+NKYKkg3XHwgm YcPRrUnkTturMqEpD/Np++P3PpJwIibrx4gfI= Received: by 10.151.144.4 with SMTP id w4mr518116ybn.202.1225941931575; Wed, 05 Nov 2008 19:25:31 -0800 (PST) Received: by 10.150.211.9 with HTTP; Wed, 5 Nov 2008 19:25:31 -0800 (PST) Message-ID: <72dbd3150811051925n50ead40cn30354990ebb8bfb6@mail.gmail.com> Date: Wed, 5 Nov 2008 19:25:31 -0800 From: "David Rees" To: pgsql-performance@postgresql.org Subject: Re: Occasional Slow Commit In-Reply-To: <72dbd3150810311714s51639bc3kfdbe03a7b51bc55c@mail.gmail.com> 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> X-Archive-Number: 200811/19 X-Sequence-Number: 31750 On Fri, Oct 31, 2008 at 4:14 PM, David Rees wrote: > Well, I'm pretty sure the delays are not checkpoint related. None of > the slow commits line up at all with the end of checkpoints. > > The period of high delays occur during the same period of time each > week, but it's not during a particularly high load period on the > systems. > > It really seems like there must be something running in the background > that is not showing up on the system activity logs, like a background > RAID scrub or something. OK, I finally had a chance to dig at this problem some more, and after futzing around with the MegaCli tools (major PITA, btw), I was able to confirm that there is a feature called "Patrol Read" on this LSI Megaraid SAS card which runs a weekly background read scan of the disks looking for errors. It is during this time period that I get lots of slow commits and transactions. FWIW, the card identifies itself from lspci as this: LSI Logic / Symbios Logic MegaRAID SAS Subsystem: Intel Corporation SROMBSAS18E RAID Controller 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. :-( Anyway, has anyone done any benchmarking of MegaRAID SAS controllers? I am configuring my arrays to use these settings: Read Policy: Normal (Normal, Read ahead & Adaptive read head) Write Policy: Writeback (Writeback, Writethrough) Disable Writeback if bad BBU IO Policy: Direct (Direct, Cached) Disk Cache: Enable (Enable, Disable, Unchanged) The only setting I'm really concerned about is the Disk Cache setting - is it safe to assume that the controller will do the right thing with regards to flushing the disk cache when appropriate to avoid data loss? LSI RAID cards seem to be pretty well respected, so I'd have to guess yes. Thanks Dave