From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Gregg Jaskiewicz <gryzman(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>, Niels Kristian Schjødt <nielskristian(at)autouncle(dot)com> |
Subject: | Re: New server setup |
Date: | 2013-03-14 18:54:24 |
Message-ID: | 20130314185424.GA28770@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Mar 12, 2013 at 09:41:08PM +0000, Gregg Jaskiewicz wrote:
> On 10 March 2013 15:58, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>
> On 3/1/13 6:43 AM, Niels Kristian Schjødt wrote:
>
> Hi, I'm going to setup a new server for my postgresql database, and I
> am considering one of these: http://www.hetzner.de/hosting/
> produkte_rootserver/poweredge-r720 with four SAS drives in a RAID 10
> array. Has any of you any particular comments/pitfalls/etc. to mention
> on the setup? My application is very write heavy.
>
>
> The Dell PERC H710 (actually a LSI controller) works fine for write-heavy
> workloads on a RAID 10, as long as you order it with a battery backup unit
> module. Someone must install the controller management utility and do
> three things however:
>
>
> We're going to go with either HP or IBM (customer's preference, etc).
>
>
>
> 1) Make sure the battery-backup unit is working.
>
> 2) Configure the controller so that the *disk* write cache is off.
Only use SSDs with a BBU cache, and don't set SSD caches to
write-through because an SSD needs to cache the write to avoid wearing
out the chips early, see:
http://momjian.us/main/blogs/pgblog/2012.html#August_3_2012
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Artur Zając | 2013-03-14 19:22:07 | Speed of EXCECUTE in PL/PGSQL |
Previous Message | Emre Hasegeli | 2013-03-14 17:07:28 | Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks |