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

Re: Effects of setting linux block device readahead size

From: david(at)lang(dot)hm
To: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
Cc: Scott Carey <scott(at)richrelevance(dot)com>, 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-13 21:21:51
Message-ID: alpine.DEB.1.10.0809131421100.17867@asgard.lang.hm (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, 12 Sep 2008, James Mansion wrote:

> 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.

I'm pretty sure that's not possible. the OS isn't supposed to even know 
the internals of the drive.

David Lang

> James
>
>> 
>> On Thu, Sep 11, 2008 at 12:54 PM, James Mansion 
>> <james(at)mansionfamily(dot)plus(dot)com <mailto: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
>>     <mailto:pgsql-performance(at)postgresql(dot)org>)
>>     To make changes to your subscription:
>>     http://www.postgresql.org/mailpref/pgsql-performance
>> 
>> 
>
>
>

In response to

pgsql-performance by date

Next:From: davidDate: 2008-09-13 21:26:40
Subject: Re: Choosing a filesystem
Previous:From: H. HallDate: 2008-09-12 18:07:09
Subject: Re: Postgres Performance on CPU limited Platforms

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