On Thu, Sep 11, 2008 at 3:36 PM, <david@xxxxxxx> wrote: > 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. Generally speaking I agree, but I would still make a separate logical partition for pg_xlog so that if the OS fills up the /var/log dir or something, it doesn't impact the db.
