Re: partition question for new server setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



are there any other xfs settings that should be tuned for postgres?

I see this post mentions "allocation groups."  does anyone have
suggestions for those settings?
http://archives.postgresql.org/pgsql-admin/2009-01/msg00144.php

what about raid stripe size?  does it really make a difference?  I
think the default for the perc is 64kb (but I'm not in front of the
server right now).

-Whit


On Tue, Apr 28, 2009 at 7:40 PM, Scott Carey <scott@xxxxxxxxxxxxxxxxx> wrote:
> On 4/28/09 11:16 AM, "Craig James" <craig_james@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-performance
>>
>
>

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


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux