Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 6A448635675 for ; Wed, 1 Apr 2009 05:27:02 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 43095-06-4 for ; Wed, 1 Apr 2009 05:26:52 -0300 (ADT) X-Greylist: delayed 00:15:01.089145 by SQLgrey-1.7.6 Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mail.postgresql.org (Postfix) with ESMTP id BB1A56355C6 for ; Wed, 1 Apr 2009 05:26:50 -0300 (ADT) Received: from zmori.markir.net (121-73-184-50.dsl.telstraclear.net [121.73.184.50]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0KHE00E5RXFLHR30@smtp4.clear.net.nz> for pgsql-performance@postgresql.org; Wed, 01 Apr 2009 21:11:46 +1300 (NZDT) Date: Wed, 01 Apr 2009 21:11:45 +1300 From: Mark Kirkwood Subject: Re: Raid 10 chunksize In-reply-to: To: Scott Carey Cc: "pgsql-performance@postgresql.org" Message-id: <49D321C1.1000405@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Thunderbird 2.0.0.19 (X11/20090117) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200904/2 X-Sequence-Number: 33369 Scott Carey wrote: > On 3/25/09 9:28 PM, "Mark Kirkwood" wrote: > > >> >> Rebuilt with 64K chunksize: >> >> transaction type: TPC-B (sort of) >> scaling factor: 100 >> number of clients: 24 >> number of transactions per client: 12000 >> number of transactions actually processed: 288000/288000 >> tps = 866.512162 (including connections establishing) >> tps = 866.651320 (excluding connections establishing) >> >> >> So 64K looks quite a bit better. I'll endeavor to try out 256K next week >> too. >> > > Just go all the way to 1MB, md _really_ likes 1MB chunk sizes for some > reason. Benchmarks right and left on google show this to be optimal. My > tests with md raid 0 over hardware raid 10's ended up with that being > optimal as well. > > Greg's notes on aligning partitions to the chunk are key as well. > > Rebuilt with 256K chunksize: transaction type: TPC-B (sort of) scaling factor: 100 number of clients: 24 number of transactions per client: 12000 number of transactions actually processed: 288000/288000 tps = 942.852104 (including connections establishing) tps = 943.019223 (excluding connections establishing) A noticeable improvement again. I'm not sure that we will have time (or patience from the system guys that I keep bugging to redo the raid setup!) to try 1M, but 256K gets us 40% or so improvement over the original 4K setup - which is quite nice! Looking on the net for md raid benchmarks, it is not 100% clear to me that 1M is the overall best - several I found had tested sizes like 64K, 128K, 512K, 1M and concluded that 1M was best - but without testing 256K! whereas others had included ranges <=512K and decided that that 256K was the best. I'd be very interested in seeing your data! (several years ago I had carried out this type of testing - on a different type of machine, and for a different database vendor, but found that 256K seemed to give the overall best result). The next step is to align the raid 10 partitions, as you and Greg suggest and see what effect that has! Thanks again Mark