6130 storage profile segment sizes

The RAID stripe unit makes a difference, but its impact on your over all performance depends on the workload composition, and such considerations as load level (number of concurrent I/O threads) read / write ratio, access type (Random Read,RW,SR,SW) and overall access density e.g. how much turnover, what truly active data set size is there (locality of reference) and how sustained it is. These considerations determine how effective the array will be.

Also, read vs. write is a big deal for RAID-5; you will not want to saturate the cache with small RW or you can get in trouble. If your update workload is not sustained, but is cache friendly, with interspersed idle time, the array bounces back nicely and you get a higher effective rate than you can actually sustain.

If you have a very intense update environment with a high performance requirement you had better use RAID-1+0, or be ready to spread the load over more LUNS to get the response you want.

RAID-5 is very good for random read.

For random I/O it is best to hit one drive with each I/O. So you want the stripe unit to be large relative to the I/O size. For sequential I/O, if you are going for high bandwidth, you will want a single I/O to span drives. So the stripe unit is small relative to the I/O size. An even multiple is a good idea. For RAID-5 sequential writes you want to align the I/O size with the stripe width (number of data drives in the LUN).

To make a long story short, the best way to find out is to try it. Find out what the primary load level, I/O size and access types are that characterize your workload, and try them on the array with a load generator. Look at both bursts (1 second) and sustained (30-120 seconds) and take measurements for a single representative LUN for each of a range of stripe units and primary access types in your workload.

The most important thing to understand is the relation of load level to the number of spindles allocated. Load level tends to be divided more or less evenly by the number of data drives in the LUN (if configured properly!) and yields load-level-per-data-drive, which in turn yields response-time-per-data-drive. The response time you get at the data drive is reflected at the LUN level.

When you split up your drives there is always the chance a disproportionate amount of the work will pile up on some of them. You can avoid this problem by being aware of your workload and allocating the resource with a specific expectation of what the average and max load levels will be per LUN.

Too few I/O threads are as much a problem as too many, as you can not get the performance the array is capable of unless you hit it hard enough.

All of this is at the heart of storage configuration design and optimization; right sizing the allocation (how you split up the drives and what you put where), and configuring the array LUN according to the particular needs of the application components that live there.

Good question!

daveCfisk at 2007-7-5 17:54:29 >

Hi Jim,

The only way to be certain is to run the array through

a profiling procedure, creating a baseline measurement

for each primary I/O size access type combination,

from 1 thread to saturation, for each stripe unit.

The result is an empirical definition of the array齭

gradient of response time with respect to load level,

and defines the potential of the array for any

workload. This is obviously a lot of data, and takes

a significant amount of runtime to produce, so you may

want to focus in on what matters to your workload. An

example of this type of analysis is on Sun齭 iForce

Customer Benchmark Center Director齭 weblog:

<a href="http://blogs.sun.com/roller/page/mrbenchmark/20050420" target="_blank">http://blogs.sun.com/roller/page/mrbenchmark/20050420</a& gt;

To be less abstract, you may find, for example, that a

smaller stripe unit favors smaller random I/O on

RAID-5, while a larger stripe unit favors sequential

I/O, or larger random I/O. I have seen as much as 100

IOPS difference per LUN with different stripe units

for the same I/O size access type combination. If you

have many LUNS, this adds up.

The idea is to discover your workload composition,

then explore the array齭 handling of that composition

with different stripe units. You can do this one

primary I/O size access type combination at a time.

There are tools to automate this.

Regards,

Dave

daveCfisk at 2007-7-5 17:54:29 >