Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id D3DE763367E for ; Thu, 3 Jun 2010 15:27:49 -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 86621-10 for ; Thu, 3 Jun 2010 18:27:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mail.postgresql.org (Postfix) with ESMTP id 8227D6335D4 for ; Thu, 3 Jun 2010 15:27:42 -0300 (ADT) Received: from [192.168.0.105] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Lb8B7-1P40I90Wk5-00kfck; Thu, 03 Jun 2010 20:27:40 +0200 Message-ID: <4C07F41A.1080501@2ndquadrant.com> Date: Thu, 03 Jun 2010 14:27:38 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Craig James CC: pgsql-performance@postgresql.org Subject: Re: Weird XFS WAL problem References: <4C06E994.2080905@emolecules.com> <4C06EC01.3060506@catalyst.net.nz> <4C07E103.9020909@emolecules.com> In-Reply-To: <4C07E103.9020909@emolecules.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+qwxznm9l968f/TuUmv5335G9DFbD8Ws+fSuc N+cPyrgLilkL9ebkua8dLkWAFpTKBDj1Hs7JxTLQARWOq9Azq8 QxmMsUshFpBmuCfSqJji9AqnDy8HRoy X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.8 tagged_above=-10 required=5 tests=BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201006/61 X-Sequence-Number: 38917 Craig James wrote: > 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. Commit performance is a separate number to measure that is not reflected in any benchmark that tests sequential performance. I consider it the fourth axis of disk system performance (seq read, seq write, random IOPS, commit rate), and directly measure it with the sysbench fsync test I recommended already. (You can do it with the right custom pgbench script too). You only get one commit per rotation on a drive, which is exactly what you're seeing: a bit under the 120 spins/second @ 7200 RPM. Attempts to time things just right to catch more than one sector per spin are extremely difficult to accomplish, I spent a week on that once without making any good progress. You can easily get 100MB/s on reads and writes but only manage 100 commits/second. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us