From: Scott Marlowe <smarlowe@g2switchworks.com>
To: jason@ohloh.net
Cc: Geoff Tolley <geoff@polimetrix.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: SCSI vs SATA
Date: Thu, 05 Apr 2007 10:03:45 -0500
Message-ID: <1175785425.9839.14.camel@state.g2switchworks.com> (raw)
In-Reply-To: <DF6C723E-7362-4173-8309-B8AAFC968E2C@ohloh.net>
References: <9C0858F5-0A48-4AF9-80FF-E4BA14F0F965@ohloh.net>
<E1HYs6Y-0008O5-SN@elasmtp-banded.atl.sa.earthlink.net>
<E1HYsBX-0006ZE-JG@elasmtp-banded.atl.sa.earthlink.net>
<4613053F.5070401@polimetrix.com>
<DF6C723E-7362-4173-8309-B8AAFC968E2C@ohloh.net>
On Wed, 2007-04-04 at 09:12, jason@ohloh.net wrote:
> On Apr 3, 2007, at 6:54 PM, Geoff Tolley wrote:
>
> > But what's likely to make the largest difference in the OP's case
> > (many inserts) is write caching, and a battery-backed cache would
> > be needed for this. This will help mask write latency differences
> > between the two options, and so benefit SATA more. Some 3ware cards
> > offer it, some don't, so check the model.
>
> The servers are hooked up to a reliable UPS. The battery-backed cache
> won't hurt but might be overkill (?).
Just had to mention that the point of battery backed cache on the RAID
controller isn't the same as for a UPS on a system.
With drives that properly report fsync(), your system is limited to the
rpm of the drive( subsystem) that the pg_xlog sits upon. With battery
backed cache, the controller immediately acknowledges an fsync() call
and then commits it at its leisure. Should the power be lost, either
due to mains / UPS failure or internal power supply failure, the
controller hangs onto those data for several days, and upon restart
flushes them out to the drives they were heading for originally.
battery backed cache is the best way to get both good performance and
reliability from a system without breaking the bank. I've seen 2 disk
RAID-1 setups with BBU beat some pretty big arrays that didn't have a
BBU on OLTP work.
> > How the drives are arranged is going to be important too - one big
> > RAID 10 is going to be rather worse than having arrays dedicated to
> > each of pg_xlog, indices and tables, and on that front the SATA
> > option is going to grant more flexibility.
>
> I've read some recent contrary advice. Specifically advising the
> sharing of all files (pg_xlogs, indices, etc..) on a huge raid array
> and letting the drives load balance by brute force.
The other, at first almost counter-intuitive result was that putting
pg_xlog on a different partition on the same array (i.e. one big
physical partition broken up into multiple logical ones) because the OS
overhead of writing all the data to one file system caused performance
issues. Can't remember who reported the performance increase of the top
of my head.
Note that a lot of the advantages to running on multiple arrays etc...
are somewhat negated by having a good RAID controller with a BBU.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: smarlowe@g2switchworks.com, jason@ohloh.net, geoff@polimetrix.com
Subject: Re: SCSI vs SATA
In-Reply-To: <1175785425.9839.14.camel@state.g2switchworks.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox