pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedDifferent disks for xlogs and data
2+ messages / 2 participants
[nested] [flat]
* Different disks for xlogs and data
@ 2006-02-28 09:45 Javier Somoza <jsomoza@pandasoftware.es>
0 siblings, 1 reply; 2+ messages in thread
From: Javier Somoza @ 2006-02-28 09:45 UTC (permalink / raw)
To: pgsql-performance
Hi,
is interesting to do it when using RAID 1+0?
Thx
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Different disks for xlogs and data
@ 2006-02-28 13:40 Ron <rjpeace@earthlink.net>
parent: Javier Somoza <jsomoza@pandasoftware.es>
0 siblings, 0 replies; 2+ messages in thread
From: Ron @ 2006-02-28 13:40 UTC (permalink / raw)
To: Javier Somoza <jsomoza@pandasoftware.es>; pgsql-performance
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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2006-02-28 13:40 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-02-28 09:45 Different disks for xlogs and data Javier Somoza <jsomoza@pandasoftware.es>
2006-02-28 13:40 ` Ron <rjpeace@earthlink.net>
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