Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 9991A6344A4 for ; Thu, 3 Jun 2010 14:06:24 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 65425-05-5 for ; Thu, 3 Jun 2010 17:06:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mail.postgresql.org (Postfix) with ESMTP id 72098634296 for ; Thu, 3 Jun 2010 14:06:16 -0300 (ADT) Received: by pzk6 with SMTP id 6so170160pzk.1 for ; Thu, 03 Jun 2010 10:06:15 -0700 (PDT) Received: by 10.143.153.22 with SMTP id f22mr6823579wfo.126.1275584775567; Thu, 03 Jun 2010 10:06:15 -0700 (PDT) Received: from Craig-Jamess-MacBook-Pro.local (wsip-70-167-124-126.sd.sd.cox.net [70.167.124.126]) by mx.google.com with ESMTPS id e16sm232847wfg.2.2010.06.03.10.06.13 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 10:06:14 -0700 (PDT) Message-ID: <4C07E103.9020909@emolecules.com> Date: Thu, 03 Jun 2010 10:06:11 -0700 From: Craig James User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Weird XFS WAL problem References: <4C06E994.2080905@emolecules.com> <4C06EC01.3060506@catalyst.net.nz> In-Reply-To: <4C06EC01.3060506@catalyst.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201006/56 X-Sequence-Number: 38912 On 6/2/10 4:40 PM, Mark Kirkwood wrote: > On 03/06/10 11:30, Craig James wrote: >> I'm testing/tuning a new midsize server and ran into an inexplicable >> problem. With an RAID10 drive, when I move the WAL to a separate RAID1 >> drive, TPS drops from over 1200 to less than 90! I've checked >> everything and can't find a reason. > > Are the 2 new RAID1 disks the same make and model as the 12 RAID10 ones? Yes. > Also, are barriers *on* on the RAID1 mount and off on the RAID10 one? It was the barriers. "barrier=1" isn't just a bad idea on ext4, it's a disaster. pgbench -i -s 100 -U test pgbench -c 10 -t 10000 -U test Change WAL to barrier=0 tps = 1463.264981 (including connections establishing) tps = 1463.725687 (excluding connections establishing) Change WAL to noatime, nodiratime, barrier=0 tps = 1479.331476 (including connections establishing) tps = 1479.810545 (excluding connections establishing) Change WAL to barrier=1 tps = 82.325446 (including connections establishing) tps = 82.326874 (excluding connections establishing) This is really hard to believe, because the bonnie++ numbers and dd(1) numbers look good (see my original post). But it's totally repeatable. It must be some really unfortunate "just missed the next sector going by the write head" problem. So with ext4, bonnie++ and dd aren't the whole story. BTW, I also learned that if you edit /etc/fstab and use "mount -oremount" it WON'T change "barrier=0/1" unless it is explicit in the fstab file. That is, if you put "barrier=0" into /etc/fstab and use the remount, it will change it to no barriers. But if you then remove it from /etc/fstab, it won't change it back to the default. You have to actually put "barrier=1" if you want to get it back to the default. This seems like a bug to me, and it made it really hard to track this down. "mount -oremount" is not the same as umount/mount! Craig