Re: Initial prefetch performance testing - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Initial prefetch performance testing
Date
Msg-id 87skrrugur.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Initial prefetch performance testing  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: Initial prefetch performance testing  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greg Smith <gsmith@gregsmith.com> writes:

> On Mon, 22 Sep 2008, Gregory Stark wrote:
>
>> Hm, I'm disappointed with the 48-drive array here. I wonder why it maxed out
>> at only 10x the bandwidth of one drive. I would expect more like 24x or more.
>
> The ZFS RAID-Z implementation doesn't really scale that linearly.  It's rather
> hard to get the full bandwidth out of a X4500 with any single process, and I
> haven't done any filesystem tuning to improve things--everything is at the
> defaults.

Well random access i/o will fall pretty far short of the full bandwidth.
Actually this is a major issue, our sequential_page_cost vs random_page_cost
dichotomy doesn't really work when we're prefetching pages.

In my experiments an array capable of supplying about 1.4GB/s in sequential
i/o could only muster about 40MB/s of random i/o with prefetching and only
about 5MB/s without.

For this machine we would have quite a dilemma setting random_page_cost -- do
we set it to 280 or 35?

Perhaps access paths which expect to be able to prefetch most of their
accesses should use random_page_cost / effective_spindle_count for their i/o
costs?

But then if people don't set random_page_cost high enough they could easily
find themselves with random fetches being costed as less expensive than
sequential fetches. And I have a feeling it'll be a hard sell to get people to
set random_page_cost in the double digits let alone triple digits.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: WIP patch: Collation support
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: pg_type.h regression?