On May 16, 2013, at 6:01 AM, Shaun Thomas wrote:

> On 05/15/2013 08:04 PM, Ramsey Gurley wrote:
> 
>> My question: Is that advice just for the database drive, or should I
>> increase read ahead on the OS/WAL disk as well?
> 
> Definitely the database drive, but it doesn't hurt to do both. It doesn't 
> mention it in the book, but if you have a Debian or Ubuntu system, you can 
> set it up to retain these settings through reboots very easily. The udev 
> system can be set with rules that can target whole ranges of devices. Here's 
> one we use:
> 
> * In a file named /etc/udev/rules.d/20-pg.rules
> 
> ACTION=="add|change", KERNEL=="sd[a-z]",ATTR{queue/read_ahead_kb}="4096"
> 
> Our systems are also NVRAM based, so we also throw in a NOOP access scheduler:
> 
> ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="noop"
> 
> There's really no reason to do it any other way if you have udev installed. 
> You *could* put blockdev calls in /etc/rc.local I suppose, but udev applies 
> rules at device detection, which can be beneficial.


Interesting point. I had not considered whether the setting would be maintained 
through reboots. I'll have to google for the appropriate settings on Red Hat.


>> I assume both. I should ask the same for noatime advice while I'm at
>> it.
> 
> You can probably get away with relatime, which is the default for most modern 
> systems these days.



I will probably go with noatime on the data drive then. I see where that would 
require lots of reads and should not be writing to the drive. In my mind, WAL 
should be read much less frequently. Maybe I am wrong about that :-)

Thank you,

Ramsey



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to