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

Re: Effects of setting linux block device readahead size

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: david(at)lang(dot)hm
Cc: "Scott Carey" <scott(at)richrelevance(dot)com>, "James Mansion" <james(at)mansionfamily(dot)plus(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-11 21:40:15
Message-ID: dcc563d10809111440q414c5285j5bff925fad310b41@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, Sep 11, 2008 at 3:36 PM,  <david(at)lang(dot)hm> 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.

In response to

Responses

pgsql-performance by date

Next:From: davidDate: 2008-09-11 22:33:53
Subject: Re: Effects of setting linux block device readahead size
Previous:From: davidDate: 2008-09-11 21:36:32
Subject: Re: Effects of setting linux block device readahead size

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