From: James Mansion <james@mansionfamily.plus.com>
To: Scott Carey <scott@richrelevance.com>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Effects of setting linux block device readahead size
Date: Fri, 12 Sep 2008 10:05:49 +0100
Message-ID: <48CA30ED.7030707@mansionfamily.plus.com> (raw)
In-Reply-To: <a1ec7d000809111336m8027c74u62c9a3567ee7301f@mail.gmail.com>
References: <70c01d1d0809092353r4ae687a3ycf3d99d43a5680cf@mail.gmail.com>
<Pine.GSO.4.64.0809101023520.15181@westnet.com>
<a1ec7d000809100926w28a4a57dy7c13f2942edc57ff@mail.gmail.com>
<Pine.GSO.4.64.0809101313070.4714@westnet.com>
<48C8AACD.5090702@mansionfamily.plus.com>
<Pine.GSO.4.64.0809110150070.3993@westnet.com>
<48C97793.2070909@mansionfamily.plus.com>
<a1ec7d000809111336m8027c74u62c9a3567ee7301f@mail.gmail.com>
Scott Carey wrote:
> Consumer drives will often read-ahead much more than server drives
> optimized for i/o per second.
...
> 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.
So ... fiddling with settings in Linux is going to force read-ahead, but
the read-ahead data will hit the controller cache and the system buffers.
And the drives use their caches for cyclinder caching implicitly (maybe
the SATA drives appear to preread more because the storage density per
cylinder is higher?)..
But is there any way for an OS or application to (portably) ask SATA,
SAS or SCSI drives to read ahead more (or less) than their default and
NOT return the data to the controller?
I've never heard of such a thing, but I'm no expert in the command sets
for any of this stuff.
James
>
> On Thu, Sep 11, 2008 at 12:54 PM, James Mansion
> <james@mansionfamily.plus.com <mailto:james@mansionfamily.plus.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@postgresql.org
> <mailto:pgsql-performance@postgresql.org>)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: james@mansionfamily.plus.com, scott@richrelevance.com, gsmith@gregsmith.com
Subject: Re: Effects of setting linux block device readahead size
In-Reply-To: <48CA30ED.7030707@mansionfamily.plus.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox