Message-ID: <5134AD18.6090901@richardneill.org>
Date: Mon, 04 Mar 2013 14:18:00 +0000
From: Richard Neill <rn214@richardneill.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Niels_Kristian_Schj=F8dt?=
 <nielskristian@autouncle.com>
CC: pgsql-performance@postgresql.org
Subject: Re: What setup would you choose for postgresql 9.2 installation?
References: <31E8EC2A-72E9-419A-9CDD-5B646A534272@autouncle.com>
In-Reply-To: <31E8EC2A-72E9-419A-9CDD-5B646A534272@autouncle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


On 04/03/13 13:52, Niels Kristian Schj=F8dt wrote:
> LSI MegaRAID SAS 9260-4i with four Intel SSDSC2CW240A3K5 SSDs OR four Hit=
achi Ultrastar 15K600 SAS drives?
>
> My app is pretty write heavy and I have a lot of concurrent connections 3=
00 - (though considering adding pgpool2 in front to increase throughput).
>

If you can afford it, there's no question in my mind that SSDs are the=20
way to go. They can be 1000 times faster for random reads.

May I suggest that you do some experiments though - perhaps with just=20
one disk of each type - you can get some pretty good illustrative tests=20
with ordinary SATA drives in an ordinary laptop/desktop (but not a USB=20
adapter). I did this originally when evaluating the (then new) Intel X25=20
SSD.

The other things to note are:

* The filesystem matters. For the important thing, fdatasync(), ext2 is=20
2x as fast as ext4, which itself is much faster than ext3. BUT ext2's=20
fsck is horrid, so we chose ext4.

* Will you enable the disk (or RAID controller) write cache?

* Have you enough RAM for your key tables (and indexes) to fit in=20
memory? If not, 64GB of RAM is cheap these days.

* In some applications, you can get a speed boost by turning=20
synchronous_commit off - this would mean that in a database crash, the=20
last few seconds are potentially lost, even through they application=20
thinks they were committed. You may find this an acceptable tradeoff.

* Postgres doesn't always write straight to the tables, but uses the WAL=20
(write-ahead-log). So the benefit of SSD performance for "random writes"=20
is less relevant than for "random reads".


Lastly, don't overdo the concurrent connections. You may end up with=20
less thoughput than  if you let postgres devote more resources to each=20
request and let it finish faster.


Hope that helps,

Richard


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