Re: Effects of setting linux block device readahead size

On Thu, 11 Sep 2008, Scott Carey wrote:

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

that extra I/O will be merged with your request by the I/O scheduler code
so that by the time it gets to the drive it will be a single request.

by even if it didn't, most modern drives read the entire cylinder into
their buffer so any additional requests to the drive will be satisfied
from this buffer and not have to wait for the disk itself.

David Lang

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