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@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
