Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 4669712FE952 for ; Thu, 5 Apr 2012 17:07:07 -0300 (ADT) Received: from [2001:1528:137::f1] (helo=mail.gransy.com) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SFsxU-0005c3-F8 for pgsql-performance@postgresql.org; Thu, 05 Apr 2012 20:07:06 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id B65E8508621 for ; Thu, 5 Apr 2012 22:06:49 +0200 (CEST) Received: from mail.gransy.com ([82.208.29.194]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id vSf9kdQsQTx9 for ; Thu, 5 Apr 2012 22:06:49 +0200 (CEST) Received: by mail.gransy.com (Postfix, from userid 5000) id 74CC8508625; Thu, 5 Apr 2012 22:06:49 +0200 (CEST) Received: from [192.168.1.237] (ip-78-45-133-255.net.upcbroadband.cz [78.45.133.255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id 58597508621 for ; Thu, 5 Apr 2012 22:06:49 +0200 (CEST) Message-ID: <4F7DFB59.10607@fuzzy.cz> Date: Thu, 05 Apr 2012 22:06:49 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 CC: "pgsql-performance@postgresql.org" Subject: Re: H800 + md1200 Performance problem References: <920BB532-C321-45A3-851E-8B688A5963F7@yahoo.com> <4F7AF966.20809@fuzzy.cz> <4F7B3AEC.4000204@fuzzy.cz> <4F7CA614.8060008@fuzzy.cz> <1333631401.49335.YahooMailNeo@web171401.mail.ir2.yahoo.com> <4F7DBF24.5010402@fuzzy.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:1528:137::f1 (failed) X-Pg-Spam-Score: -0.1 (/) X-Archive-Number: 201204/72 X-Sequence-Number: 46718 On 5.4.2012 20:43, Merlin Moncure wrote: > The original problem is read based performance issue though and this > will not have any affect on that whatsoever (although it's still > excellent advice). Also dd should bypass the o/s buffer cache. I > still pretty much convinced that there is a fundamental performance > issue with the raid card dell needs to explain. Well, there are two issues IMHO. 1) Read performance that's not exactly as good as one'd expect from a 12 x 15k SAS RAID10 array. Given that the 15k Cheetah drives usually give like 170 MB/s for sequential reads/writes. I'd definitely expect more than 533 MB/s when reading the data. At least something near 1GB/s (equal to 6 drives). Hmm, the dd read performance seems to grow over time - I wonder if this is the issue with adaptive read policy, as mentioned in the xbitlabs report. Cesar, can you set the read policy to a 'read ahead' megacli -LDSetProp RA -LALL -aALL or maybe 'no read-ahead' megacli -LDSetProp NORA -LALL -aALL It's worth a try, maybe it somehow conflicts with the way kernel handles read-ahead or something. I find these adaptive heuristics a bit unpredictable ... Another thing - I see the patrol reads are enabled. Can you disable that and try how that affects the performance? 2) Write performance behaviour, that's much more suspicious ... Not sure if it's related to the read performance issues. Tomas