In my sporadic benchmark testing, the only consistent 'trick' I found
was that the best thing I could do for performance sequential
performance was allocating a bunch of mirrored pair LUNs and stripe
them with software raid. This made a huge difference (~2X) in sequential
performance, and a little boost in random i/o - at least in FLARE 19.
On our CX-500s, FLARE failed to fully utilize the secondary drives in
RAID 1+0 configurations. FWIW, after several months of inquiries, EMC
eventually explained that this is due to their desire to ease the usage
and thus wear on the secondaries in order to reduce the likelihood of a
mirrored pair both failing.
We've never observed a difference using separate WAL LUNs - presumably
due to the write cache. That said, we continue to use them figuring it's
"cheap" insurance against running out of space as well as performance
under conditions we didn't see while testing.
We also ended up using single large LUNs for data, but I must admit I
wanted more time to benchmark splitting off heavily hit tables.
My advice would be to read the EMC performance white papers, remain
skeptical, and then test everything yourself. :D
On Wed, 2007-07-11 at 09:03 -0400, Dave Cramer wrote:
> Assuming we have 24 73G drives is it better to make one big metalun
> and carve it up and let the SAN manage the where everything is, or is
> it better to specify which spindles are where.
>
> Currently we would require 3 separate disk arrays.
>
> one for the main database, second one for WAL logs, third one we use
> for the most active table.
>
> Problem with dedicating the spindles to each array is that we end up
> wasting space. Are the SAN's smart enough to do a better job if I
> create one large metalun and cut it up ?
>
> Dave
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
