Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 9F6682E035F for ; Tue, 4 Dec 2007 11:41:54 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 07666-06 for ; Tue, 4 Dec 2007 11:41:51 -0400 (AST) Received: from ironport2-out.pppoe.ca (ironport2-out.pppoe.ca [206.248.154.182]) by postgresql.org (Postfix) with ESMTP id B08412E025E for ; Tue, 4 Dec 2007 11:41:51 -0400 (AST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJ8DVUfO+Igp/2dsb2JhbACCPTY X-IronPort-AV: E=Sophos;i="4.23,249,1194238800"; d="scan'208,217";a="10768012" Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 04 Dec 2007 10:41:49 -0500 Received: from [206.248.136.41] ([206.248.136.41]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id JBT05450; Tue, 04 Dec 2007 10:41:50 -0500 Message-ID: <47557519.6090506@mark.mielke.cc> Date: Tue, 04 Dec 2007 10:41:13 -0500 From: Mark Mielke User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Matthew CC: pgsql-performance@postgresql.org Subject: Re: RAID arrays and performance References: <87lk8aiqf3.fsf@oxford.xeocode.com> <475559F4.7060104@mark.mielke.cc> <4755648C.90905@mark.mielke.cc> <87fxyiik94.fsf@oxford.xeocode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030800030609060705030601" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/41 X-Sequence-Number: 27857 This is a multi-part message in MIME format. --------------030800030609060705030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Matthew wrote: > On Tue, 4 Dec 2007, Gregory Stark wrote: > >> Also, it's true, you need to preread more than 12 blocks to handle a 12-disk >> raid. My offhand combinatorics analysis seems to indicate you would expect to >> need to n(n-1)/2 blocks on average before you've hit all the blocks. There's >> little penalty to prereading unless you use up too much kernel resources or >> you do unnecessary i/o which you never use, so I would expect doing n^2 capped >> at some reasonable number like 1,000 pages (enough to handle a 32-disk raid) >> would be reasonable. >> > It's better than that, actually. Let's assume a RAID 0 striped set of > twelve discs. If you spread out twelve requests to twelve discs, then the > expected number of requests to each disc is one. The probablility that any > single disc receives more than say three requests is rather small. As you > increase the number of requests, the longest reasonably-expected queue > length for a particular disc gets closer to the number of requests divided > by the number of discs, as the requests get spread more and more evenly > among the discs. > > The larger the set of requests, the closer the performance will scale to > the number of discs This assumes that you can know which pages to fetch ahead of time - which you do not except for sequential read of a single table. I think it would be possible that your particular case could be up to 6X faster, but that most other people will see little or no speed up. If it does read the wrong pages, it is wasting it's time. I am not trying to discourage you - only trying to ensure that you have reasonable expectations. 12X is far too optimistic. Please show one of your query plans and how you as a person would design which pages to request reads for. Cheers, mark -- Mark Mielke --------------030800030609060705030601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Matthew wrote: 
On Tue, 4 Dec 2007, Gregory Stark wrote:
  
Also, it's true, you need to preread more than 12 blocks to handle a 12-disk
raid. My offhand combinatorics analysis seems to indicate you would expect to
need to n(n-1)/2 blocks on average before you've hit all the blocks. There's
little penalty to prereading unless you use up too much kernel resources or
you do unnecessary i/o which you never use, so I would expect doing n^2 capped
at some reasonable number like 1,000 pages (enough to handle a 32-disk raid)
would be reasonable.
    
It's better than that, actually. Let's assume a RAID 0 striped set of
twelve discs. If you spread out twelve requests to twelve discs, then the
expected number of requests to each disc is one. The probablility that any
single disc receives more than say three requests is rather small. As you
increase the number of requests, the longest reasonably-expected queue
length for a particular disc gets closer to the number of requests divided
by the number of discs, as the requests get spread more and more evenly
among the discs.

The larger the set of requests, the closer the performance will scale to
the number of discs

This assumes that you can know which pages to fetch ahead of time - which you do not except for sequential read of a single table.

I think it would be possible that your particular case could be up to 6X faster, but that most other people will see little or no speed up. If it does read the wrong pages, it is wasting it's time.

I am not trying to discourage you - only trying to ensure that you have reasonable expectations. 12X is far too optimistic.

Please show one of your query plans and how you as a person would design which pages to request reads for.

Cheers,
mark

-- 
Mark Mielke <mark@mielke.cc>
--------------030800030609060705030601--