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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
