Re: partition question for new server setup

Thanks, Scott.

So far, I've followed a pattern similar to Scott Marlowe's setup.  I
have configured 2 disks as a RAID 1 volume, and 4 disks as a RAID 10
volume.  So, the OS and xlogs will live on the RAID 1 vol and the data
will live on the RAID 10 vol.

I'm running the memtest on it now, so we still haven't locked
ourselves into any choices.

regarding your comment:
> 6 and 8 disk counts are tough.  My biggest single piece of advise is to have
> the xlogs in a partition separate from the data (not necessarily a different
> raid logical volume), with file system and mount options tuned for each case
> separately.  I've seen this alone improve performance by a factor of 2.5 on
> some file system / storage combinations.

can you suggest mount options for the various partitions?  I'm leaning
towards xfs for the filesystem format unless someone complains loudly
about data corruption on xfs for a recent 2.6 kernel.

-Whit


On Tue, Apr 28, 2009 at 7:58 PM, Scott Carey <scott@richrelevance.com> wrote:
>>>
>>> server information:
>>> Dell PowerEdge 2970, 8 core Opteron 2384
>>> 6 1TB hard drives with a PERC 6i
>>> 64GB of ram
>>
>> We're running a similar configuration: PowerEdge 8 core, PERC 6i, but we have
>> 8 of the 2.5" 10K 384GB disks.
>>
>> When I asked the same question on this forum, I was advised to just put all 8
>> disks into a single RAID 10, and forget about separating things.  The
>> performance of a battery-backed PERC 6i (you did get a battery-backed cache,
>> right?) with 8 disks is quite good.
>>
>> In order to separate the logs, OS and data, I'd have to split off at least two
>> of the 8 disks, leaving only six for the RAID 10 array.  But then my xlogs
>> would be on a single disk, which might not be safe.  A more robust approach
>> would be to split off four of the disks, put the OS on a RAID 1, the xlog on a
>> RAID 1, and the database data on a 4-disk RAID 10.  Now I've separated the
>> data, but my primary partition has lost half its disks.
>>
>> So, I took the advice, and just made one giant 8-disk RAID 10, and I'm very
>> happy with it.  It has everything: Postgres, OS and logs.  But since the RAID
>> array is 8 disks instead of 4, the net performance seems to quite good.
>>
>
> If you go this route, there are a few risks:
> 1.  If everything is on the same partition/file system, fsyncs from the
> xlogs may cross-pollute to the data.  Ext3 is notorious for this, though
> data=writeback limits the effect you especially might not want
> data=writeback on your OS partition.  I would recommend that the OS, Data,
> and xlogs + etc live on three different partitions regardless of the number
> of logical RAID volumes.
> 2. Cheap raid controllers (PERC, others) will see fsync for an array and
> flush everything that is dirty (not just the partition or file data), which
> is a concern if you aren't using it in write-back with battery backed cache,
> even for a very read heavy db that doesn't need high fsync speed for
> transactions.
>
>> But ... your mileage may vary.  My box has just one thing running on it:
>> Postgres.  There is almost no other disk activity to interfere with the
>> file-system caching.  If your server is going to have a bunch of other
>> activity that generate a lot of non-Postgres disk activity, then this advice
>> might not apply.
>>
>> Craig
>>
>
> 6 and 8 disk counts are tough.  My biggest single piece of advise is to have
> the xlogs in a partition separate from the data (not necessarily a different
> raid logical volume), with file system and mount options tuned for each case
> separately.  I've seen this alone improve performance by a factor of 2.5 on
> some file system / storage combinations.
>
>>
>> --
>> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-performance
>>
>
>