Re: Tuning read ahead

From: Shaun Thomas <sthomas(at)optionshouse(dot)com>
To: Ramsey Gurley <rgurley(at)smarthealth(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Tuning read ahead
Date: 2013-05-16 13:01:45
Message-ID: 5194D8B9.7050209@optionshouse.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

> 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.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ioana Danes 2013-05-16 13:27:02 Re: Running out of memory on vacuum
Previous Message Raghavendra 2013-05-16 13:01:37 Re: Schema (Search path issue) on PostgreSQL9.2