All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Southerwood <ts@dionic.net>
To: Franck Routier <franck.routier@axege.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: 2x6 or 3x4 raid10 arrays ?
Date: Thu, 28 Feb 2008 11:22:26 +0000	[thread overview]
Message-ID: <47C69972.50508@dionic.net> (raw)
In-Reply-To: <1204195554.16924.16.camel@franck-gusty>

Franck Routier wrote:
> Hi,
> 
> I am installing a database (postgresql) server.
> I am considering two options:
> - either setup two 6 disks raid10 arrays
> - or setup three 4 disks raid10 arrays
> 
> You guessed I have 12 disks :)
> 
> Raw performance is better on 6 disks arrays, but having 3 arrays allows
> me to setup 3 tablespaces and maybe to achieve better parallelism.
> 
> I am under the impression that I will get better results with requests
> spread over 3 less effective arrays rather than two slightly more effive
> one.
> 
> Does it make any sense, or am I totally missing the point ?
> 
> Thanks,
> Franck
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi

No, it makes total sense.

Having just done a lot of work on optimising Postgresql:

How many distinct table spaces depends on your expected usage pattern - 
ie if you have one table that is hammered for updates all the time you 
might benefit from having the table storage on a physically separate 
tablespace to any indexes for that table.

If you are hammering some tables for updates whilst querying other 
tables at a high rate, placing the updating tables on a different 
tablespace to the ones you are querying may benefit.

The nice thing about Postgresql 8.1 upwards (at least I haven't tried 
this under 8.0) is that you can ALTER TABLE|INDEX to use a different 
tablespace at run time on a live database, so experimentation is easy.

However, the single biggest improvement I found was to ensure that the 
WAL is redirected to a otherwise quiescent disk.

In my case, I arranged two physically separate storage volumes thus:

VOL1: OS (/) + WAL
VOL2: DB storage (minus WAL) + /var/log

Taking /var/log off VOL1 rendered it fairly quiet after all applications 
had started and having the WAL on a quiet volume gave me a tenfold 
improvement in INSERT rate, so not insignificant.

If you are expecting heavy insert/update accesses, I would suggest you 
take two disks off as a RAID1 mirror and devote them entirely to the WAL.

Cheers

Tim

  reply	other threads:[~2008-02-28 11:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-28 10:45 2x6 or 3x4 raid10 arrays ? Franck Routier
2008-02-28 11:22 ` Tim Southerwood [this message]
2008-02-28 16:54 ` Brendan Conoboy
2008-02-28 18:25 ` Janek Kozicki
2008-02-28 20:53   ` Janek Kozicki
2008-02-28 21:04     ` Brendan Conoboy
2008-03-01 20:07     ` Bill Davidsen
2008-03-01 20:55       ` Keld Jørn Simonsen
2008-02-28 22:36 ` Nat Makarevitch
2008-03-01 20:40   ` Keld Jørn Simonsen
2008-03-01 21:10     ` Keld Jørn Simonsen
2008-03-01 22:05     ` Nat Makarevitch
2008-03-02  0:30       ` Keld Jørn Simonsen
2008-03-02  9:00         ` Nat Makarevitch
2008-03-01 20:18 ` Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47C69972.50508@dionic.net \
    --to=ts@dionic.net \
    --cc=franck.routier@axege.com \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.