Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Jean-David Beyer" <jeandavid8(at)verizon(dot)net>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
Date: 2007-09-11 18:16:03
Message-ID: 87zlzt9ifw.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Jean-David Beyer" <jeandavid8(at)verizon(dot)net> writes:

> Gregory Stark wrote (in part):
>
>> The extra spindles speed up sequential i/o too so the ratio between sequential
>> and random with prefetch would still be about 4.0. But the ratio between
>> sequential and random without prefetch would be even higher.
>>
> I never figured out how extra spindles help sequential I-O because
> consecutive logical blocks are not necessarily written consecutively in a
> Linux or UNIX file system. They try to group a bunch (8 512-bit?) of blocks
> together, but that is about it. So even if you are reading sequentially, the
> head actuator may be seeking around anyway.

That's somewhat true but good filesystems group a whole lot more than 8 blocks
together. You can do benchmarks with dd and compare the speed of reading from
a file with the speed of reading from the raw device. On typical consumer
drives these days you'll get 50-60MB/s raw and I would expect not a whole lot
less than that with a large ext2 file, at least if it's created all in one
chunk on a not overly-full filesystem.

(Those assumptions is not necessarily valid for Postgres which is another
topic, but one that requires some empirical numbers before diving into.)

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2007-09-11 18:23:20 Re: Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
Previous Message Heikki Linnakangas 2007-09-11 17:29:08 Re: More Vacuum questions...