pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Ron <rjpeace@earthlink.net>
To: Javier Somoza <jsomoza@pandasoftware.es>
To: pgsql-performance@postgresql.org
Subject: Re: Different disks for xlogs and data
Date: Tue, 28 Feb 2006 08:40:56 -0500
Message-ID: <7.0.1.0.2.20060228072910.038dacc0@earthlink.net> (raw)
In-Reply-To: <1141119945.1555.16.camel@pndsoft>
References: <1141034594.1556.15.camel@pndsoft>
	<4402D0A9.7080705@wildenhain.de>
	<1141035368.1556.22.camel@pndsoft>
	<4402D475.9020505@wildenhain.de>
	<1141119945.1555.16.camel@pndsoft>

At 04:45 AM 2/28/2006, Javier Somoza wrote:

>Hi,
>is interesting to do it (use different HD sets AKA "LUNs" for xlogs 
>than for data) when using RAID 1+0?

If "interesting" means "this increases performance", this is not a 
simple question.

Regardless of what RAID level you use, under the proper circumstances 
it can boost performance to put xlog on a dedicated set of spindles.

If you have a large enough pool of HDs so that you can maximize the 
performance of any LUN you create, then it is always good to put xlog 
on its own LUN.

In the "perfect" world, each table or set of tables that tends to be 
accessed for the same query, which obviously includes xlog, would be 
on its own LUN; and each LUN would contain enough HDs to maximize performance.

Most people can't afford and/or fit that many HDs into their set up.

If you have a small number of HDs, and "small" depends on the 
specifics of your DB and the HDs you are using, you may get better 
performance by leaving everything together on one set of HDs.

Once you have more than whatever is a "small" number of HDs for your 
DB and set of disks, _usually_, but not always, one of the best first 
tables to move to different HD's is xlog.

The best way to find out what will get the most performance from your 
specific HW and DB is to test, test, test.  Start by putting 
everything on 1 RAID 5 set.  Test.  Then (if you have enough HDs) put 
everything on 1 RAID 1+0 set.  Test again.  If performance is "good 
enough", and only you know what that is for your DB, then STOP and 
just use whichever works best for you.  It's possible to spend far 
more money in man hours of effort than it is worth trying to get a 
few extra percents of performance.

If you have the need and the budget to tweak things further, then 
start worrying about the more complicated stuff.

As a rule of thumb, figure each 7200rpm HD does ~50MBps and each 
15Krpm (or 10Krpm WD Raptor) does ~75MBps.  So a 8 HD RAID 5 set of 
7200rpm HDs does ~(8-1= 7)*50= ~350MBps. A RAID 10 set made of the 
same 8 HDs should do ~4*50= 200MBps.  (=If and only if= the rest of 
your HW let's the RAID set push data at that speed.).  Also, note 
that RAID 5 writes are often 2/3 - 4/5 the speed of RAID 5 reads.

If we pull 1 HD from the 8 HD RAID 5 set above and dedicate it to 
xlog, then xlog will always get ~50MBps bandwidth.  OTOH, in the 
original RAID 5 configuration xlog was probably sharing between 2/3 
and 4/5 of ~350MBps bandwidth.  Say ~233-280MBps.  Which results in 
higher overall performance for you DB?  Only testing by you on your 
DB can tell.

Hope this helps,
Ron





       





view thread (2+ messages)

Message-ID: <7.0.1.0.2.20060228072910.038dacc0@earthlink.net>
Permalink:  ../7.0.1.0.2.20060228072910.038dacc0@earthlink.net/
Also on:    postgresql.org/message-id/7.0.1.0.2.20060228072910.038dacc0@earthlink.net

 · 

reply

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: rjpeace@earthlink.net, jsomoza@pandasoftware.es
  Subject: Re: Different disks for xlogs and data
  In-Reply-To: <7.0.1.0.2.20060228072910.038dacc0@earthlink.net>

* 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