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
next prev parent 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.