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.
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@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Greg Smith wrote:Isn't there a bigger danger in blowing out the cache on the controller and causing premature pageout of its dirty pages?
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.
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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
