Stripe sizing and maxcontig

Hi all,

I've been reading up a lot recently on filesystem tuning, and stripe
sizing, mainly because we've just got a shiny new 3510FC array (dual
RAID controllers) and are looking at moving our databases over onto it
(Solaris 10 update 1 / AMD64 architecture, UFS filesystems).

First off - the person from the VAR who came round to demo it said that
a RAID 5 volume was perfectly OK, and we wouldn't incurr that much of a
performance hit from choosing that over, say RAID 1+0. Is this correct
? Our databases are much more read-intensive than they are write, but
still... Alarm bells are ringing at this advice even though the array
does have a hefty whack of cache on board.

Secondly - I could just use some clarification regarding my
methodologies - I would massivley appreciate someone sanity checking my
thinking here :)

I have observed our current database's IO patterns using iostat over
the course of a hour. I discovered it was doing 2921.8 kr/s and 140.1
kw/s (197.4 r/s and 13.7 w/s). This gave me an average read size of
around 14Kb, and average write size of roughly 10Kb.

My assumptions are : For random access, I'm assuming the best thing to
do is to set the stripe size of a RAID volume to the average transfer
size - so if I have, say, 4 disks in a volume they could all in theory
be handling different requests. If I'm doing mostly sequential
transfers, I'm better off setting the stripe size to (number of disks *
transfer size), so a single transfer is spread out amongst as many
disks as possible. Is this correct ?

If I've got that right, my next question relates to maxcontig. If I set
the stripe size of the RAID volume to 16Kb (closest to 14Kb value
mentioned above), I know I then need to tune maxcontig accordingly. If
I lower this from the default setting of 7 to 6, this means the system
should bunch together transfers until they reach a size of 48Kb. If I
have 4 disks in my RAID 5 volume (3 available volumes), and a stripe
size of 16Kb so that the total stripe width is also 48Kb, does that
mean that every transfer will be spread evenly across all disks ?

Is this the best way of sizing my RAID volumes and tuning them for the
best possible performance ?

Many thanks in advance,

-Mark

.

Relevant Pages

  • Re: Making a RAID array
    ... hard it might be to set up my own RAID array. ... and then set it up to do RAID. ... disks to that, but I'd like to see how easy it is to do it in the Mac ... If I add disks to the mirror set, ...
    (uk.comp.sys.mac)
  • Re: insufficient space in super block for rotational layout
    ... Occurs typically on very high density disks. ... the file system structure cannot ... Is this really an issue with a RAID 5 storage ... It doesn't sound like a problem with the array, but the size of the array. ...
    (comp.unix.solaris)
  • Re: VLDB, RAID, and clustering
    ... And clustering for windows and SQL Server is a hardware failover technology only, ... You can not have data or log files on disks outside the cluster resource groups. ... You absolutely need to ensure the transaction logs for all user and tempdb databases are separate from the data files and on a raid 1 or 10. ... You may need to segregate the tempdb data files onto their own array as well depending on usage. ...
    (microsoft.public.sqlserver.security)
  • Re: VLDB, RAID, and clustering
    ... clustering for windows and SQL Server is a hardware failover technology ... A raid 10 is recommended for the data files. ... disks in the array the better if there is high usage. ...
    (microsoft.public.sqlserver.security)
  • Re: Problems spinning down drives in RAID5 array
    ... so I guess this is a problem with the array ... *Assuming that the RAID is handled in software by the kernel's Device ... Wait - and see if the disks *do* spin down. ...
    (comp.os.linux.hardware)