Skip site navigation (1) Skip section navigation (2)

Re: Effects of setting linux block device readahead size

From: "Scott Carey" <scott(at)richrelevance(dot)com>
To: "James Mansion" <james(at)mansionfamily(dot)plus(dot)com>
Cc: "Greg Smith" <gsmith(at)gregsmith(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Effects of setting linux block device readahead size
Date: 2008-09-11 20:36:17
Message-ID: a1ec7d000809111336m8027c74u62c9a3567ee7301f@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
Drives have their own read-ahead in the firmware.  Many can keep track of 2
or 4 concurrent file accesses.  A few can keep track of more.  This also
plays in with the NCQ or SCSI command queuing implementation.

Consumer drives will often read-ahead much more than server drives optimized
for i/o per second.
The difference in read-ahead sensitivity between the two setups I tested may
be due to one setup using nearline-SAS (SATA, tuned for io-per sec using SAS
firmware) and the other used consumer SATA.
For example, here is one "nearline SAS" style server tuned drive versus a
consumer tuned one:
http://www.storagereview.com/php/benchmark/suite_v4.php?typeID=10&testbedID=4&osID=6&raidconfigID=1&numDrives=1&devID_0=354&devID_1=348&devCnt=2

The Linux readahead setting is _definitely_ in the kernel, definitely uses
and fills the page cache, and from what I can gather, simply issues extra
I/O's to the hardware beyond the last one requested by an app in certain
situations.  It does not make your I/O request larger, it just queues an
extra I/O following your request.

On Thu, Sep 11, 2008 at 12:54 PM, James Mansion <
james(at)mansionfamily(dot)plus(dot)com> wrote:

> Greg Smith wrote:
>
>> The point I was trying to make there is that even under impossibly optimal
>> circumstances, you'd be hard pressed to blow out the disk's read cache with
>> seek-dominated data even if you read a lot at each seek point.  That idea
>> didn't make it from my head into writing very well though.
>>
>>  Isn't there a bigger danger in blowing out the cache on the controller
> and causing premature pageout of its dirty pages?
>
> If you could get the readahead to work on the drive and not return data to
> the controller, that might be dandy, but I'm sceptical.
>
> James
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

In response to

Responses

pgsql-performance by date

Next:From: Scott CareyDate: 2008-09-11 20:44:40
Subject: Re: Effects of setting linux block device readahead size
Previous:From: Greg SmithDate: 2008-09-11 20:11:13
Subject: Re: Choosing a filesystem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group