Re: partition question for new server setup

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Craig James <craig_james(at)emolecules(dot)com>, Kenneth Marshall <ktm(at)rice(dot)edu>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Whit Armstrong <armstrong(dot)whit(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: partition question for new server setup
Date: 2009-04-28 23:40:24
Message-ID: C61CE1F8.5626%scott@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 4/28/09 11:16 AM, "Craig James" <craig_james(at)emolecules(dot)com> wrote:

> Kenneth Marshall wrote:
>>>> Additionally are there any clear choices w/ regard to filesystem
>>>> types? ?Our choices would be xfs, ext3, or ext4.
>>> Well, there's a lot of people who use xfs and ext3. XFS is generally
>>> rated higher than ext3 both for performance and reliability. However,
>>> we run Centos 5 in production, and XFS isn't one of the blessed file
>>> systems it comes with, so we're running ext3. It's worked quite well
>>> for us.
>>>
>>
>> The other optimizations are using data=writeback when mounting the
>> ext3 filesystem for PostgreSQL and using the elevator=deadline for
>> the disk driver. I do not know how you specify that for Ubuntu.
>
> After a reading various articles, I thought that "noop" was the right choice
> when you're using a battery-backed RAID controller. The RAID controller is
> going to cache all data and reschedule the writes anyway, so the kernal
> schedule is irrelevant at best, and can slow things down.
>
> On Ubuntu, it's
>
> echo noop >/sys/block/hdx/queue/scheduler
>
> where "hdx" is replaced by the appropriate device.
>
> Craig
>

I've always had better performance from deadline than noop, no matter what
raid controller I have. Perhaps with a really good one or a SAN that
changes (NOT a PERC 6 mediocre thingamabob).

PERC 6 really, REALLY needs to have the linux "readahead" value set up to at
least 1MB per effective spindle to get good sequential read performance.
Xfs helps with it too, but you can mitigate half of the ext3 vs xfs
sequential access performance with high readahead settings:

/sbin/blockdev --setra <value> <device>

Value is in blocks (512 bytes)

/sbin/blockdev --getra <device> to see its setting. Google for more info.

>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Carey 2009-04-28 23:58:30 Re: partition question for new server setup
Previous Message Tom Lane 2009-04-28 22:17:04 Re: pg_lock_status() performance