Skip site navigation (1) Skip section navigation (2)

Re: best use of an EMC SAN

From: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: best use of an EMC SAN
Date: 2007-07-11 18:27:01
Message-ID: 20070711182701.GB1241@phlogiston.dyndns.org (view raw or flat)
Thread:
Lists: pgsql-performance
On Wed, Jul 11, 2007 at 01:39:39PM -0400, Chris Browne wrote:
> load causes.  A fallout of this is that those disks are likely to be
> worked harder than the disk used for storing "plain old data," with
> the result that if you devote disk to WAL, you'll likely burn thru
> replacement drives faster there than you do for the "POD" disk.

This is true, and in operation can really burn you when you start to
blow out disks.  In particular, remember to factor the cost of RAID
re-build into your RAID plans.  Because you're going to be doing it,
and if your WAL is near to its I/O limits, the only way you're going
to get your redundancy back is to go noticably slower :-(

> will lose a very little bit in comparison.  Andrew Sullivan had a
> somewhat similar finding a few years ago on some old Solaris hardware
> that unfortunately isn't at all relevant today.  He basically found
> that moving WAL off to separate disk didn't affect performance
> materially.

Right, but it's not only the hardware that isn't relevant there.  It
was also using either 7.1 or 7.2, which means that the I/O pattern
was completely different.  More recently, ISTR, we did analysis for
at least one workload that tod us to use separate LUNs for WAL, with
separate I/O paths.  This was with at least one kind of array
supported by Awful Inda eXtreme.  Other tests, IIRC, came out
differently -- the experience with one largish EMC array was I think
a dead heat between various strategies (so the additional flexibility
of doing everything on the array was worth any cost we were able to
measure).  But the last time I had to be responsible for that sort of
test was again a couple years ago.  On the whole, though, my feeling
is that you can't make general recommendations on this topic: the
advances in storage are happening too fast to make generalisations,
particularly in the top classes of hardware.

A

-- 
Andrew Sullivan  | ajs(at)crankycanuck(dot)ca
The plural of anecdote is not data.
		--Roger Brinner

In response to

pgsql-performance by date

Next:From: Jignesh K. ShahDate: 2007-07-11 18:34:13
Subject: Re: PostgreSQL publishes first real benchmark
Previous:From: Jim NasbyDate: 2007-07-11 17:58:12
Subject: Re: best use of an EMC SAN

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group