From: Greg Smith <greg@2ndQuadrant.com>
To: pgsql-performance@postgresql.org
Subject: Re: Performance advice for a new low(er)-power server
Date: Thu, 16 Jun 2011 14:43:03 -0400
Message-ID: <4DFA4EB7.1020701@2ndQuadrant.com> (raw)
In-Reply-To: <BANLkTinXa4ZVigTQ7Q=05saam_3GZdyx7g@mail.gmail.com>
References: <BANLkTinXa4ZVigTQ7Q=05saam_3GZdyx7g@mail.gmail.com>
On 06/16/2011 11:09 AM, Haestan wrote:
> The cheaper option would be to buy 15k Seagate SAS disks with a 3ware
> 9750SA (battery backed) controller. Does it matter whether to use a
> 4-disk RAID10 or 2x 2-disk RAID1 (system+pg_xlog , pg_data) setup? Am
> I right that both would be faster than just using a single 2-disk
> RAID1 for everything?
>
The layout you proposed (OS+WAL , data) might be effective, but if your
write volume is low it may not be much of an improvement at all over a
simple RAID1 of two drives. The odds that you are going to correctly
lay out individual sections of a disk array with only two pairs to
spread the data across aren't good. If this is all you have to work
with, a 4-disk RAID10 would at least guarantee you're taking advantage
of all four drives. With that controller, it should be almost twice as
fast in all cases as hooking up only two drives.
> A higher end option would be to use 2x 64G Intel X-25E SSD's with a
> LSI MegaRAID 9261 controller for pg_data and/or pg_xlog and 2x SAS
> disks for the rest. Unfortunately, these SSD are the only ones offered
> by our supplier and they don't use a supercapacitor, AFAIK. Therefore
> I would have to disable the write cache on the SSD's somehow and just
> use the cache on the controller only. Does anyone know if this will
> work or even uses such a setup?
>
These drives are one of the worst choices on the market for PostgreSQL
storage. They're unusably slow if you disable the caches, and even that
isn't guaranteed to work. There is no way to make them safe. See
http://wiki.postgresql.org/wiki/Reliable_Writes for more details. The
3rd generation SSDs from Intel are much, much better; see
http://blog.2ndquadrant.com/en/2011/04/intel-ssd-now-off-the-sherr-sh.html
for details.
There is another possibility I would suggest you consider. You could
buy the server with a single pair of drives now, then wait to see what
performance is like before filling the other two slots. It is far
easier to figure out what drive technology makes sense if you have
measurements from an existing system to guide that decision. And you
may be able to get newer drives from your vendor that slide into the
empty slots. You may not ever even need more than a single RAID-1
pair. I see lots of people waste money on drives that would be better
spent on RAM.
> Furthermore, the LSI MegaRAID 9261 offers CacheCade which uses SSD
> disks a as secondary tier of cache for the SAS disks. Would this
> feature make sense for a PostgreSQL server, performance wise?
>
There are already three layers involved here:
-Database shared_buffers cache
-Operating system read/write cache
-RAID controller cache
I would be skeptical that adding a fourth one near the bottom of this
stack is likely to help a lot. And you're adding a whole new layer of
difficult to test reliability issues, too. Overly complicated storage
solutions tend to introduce complicated failures that corrupt your data
in unexpected ways.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
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: greg@2ndQuadrant.com
Subject: Re: Performance advice for a new low(er)-power server
In-Reply-To: <4DFA4EB7.1020701@2ndQuadrant.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