Re: RAID stripe size question

Yeah, it seems to be a waste of disk space (spindles as well?). I was
unsure how much activity the WAL disks would have compared to the data
disks, so I created an array from 10 disks as the application is very
write intense (many spindles / high throughput is crucial). I guess that
a mirror of two disks is enough from a disk space perspective, but from
a throughput perspective it will limit me to ~25Mb/s (roughly
calculated).

An 0+1 array of 4 disks *could* be enough, but I'm still unsure how WAL
activity correlates to "normal data" activity (is it 1:1, 1:2, 1:4,
...?)

-----Original Message-----
From: pgsql-performance-owner(at)postgresql(dot)org
[mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Michael
Stone
Sent: den 17 juli 2006 02:04
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] RAID stripe size question

On Mon, Jul 17, 2006 at 12:52:17AM +0200, Mikael Carneholm wrote:
>I have finally gotten my hands on the MSA1500 that we ordered some time

>ago. It has 28 x 10K 146Gb drives, currently grouped as 10 (for wal) +
>18 (for data). There's only one controller (an emulex), but I hope

You've got 1.4TB assigned to the WAL, which doesn't normally have more
than a couple of gigs?

Mike Stone

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Hi, Mikael,

Mikael Carneholm wrote:
> An 0+1 array of 4 disks *could* be enough, but I'm still unsure how WAL
> activity correlates to "normal data" activity (is it 1:1, 1:2, 1:4,
> ...?)

I think the main difference is that the WAL activity is mostly linear,
where the normal data activity is rather random access. Thus, a mirror
of few disks (or, with good controller hardware, raid6 on 4 disks or so)
for WAL should be enough to cope with a large set of data and index
disks, who have a lot more time spent in seeking.

Btw, it may make sense to spread different tables or tables and indices
onto different Raid-Sets, as you seem to have enough spindles.

And look into the commit_delay/commit_siblings settings, they allow you
to deal latency for throughput (means a little more latency per
transaction, but much more transactions per second throughput for the
whole system.)

HTH,
Markus

--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org