Clariion Performance Metrics to Focus On

Thank you for that feedback - that's exactly the sort of thing I'm looking for as I work to build my report models.

Also  i like monitoring disk crossings in addition and strict to the alignment at OS level , block size recommendation for application etc to get maximum benifit.

How do you correlate the RD/WR size to the performacne? More the sequential the better, Or do you have any other logics? Other way if the IOs are not sequential what you do ?

Does the high value on ABQL really matter? I have application whose LUNs reporting servicetime as well response time reporting lesser than 10(queu length less than one). But ABQL avareage above fifteen, but no performace issues. So what is peformance significance of ABQL other than indication of a "bursty" IO

For ABQL - see Primus emc204523 "What is the cause of high Queuing on CLARiiON drives? "

Also, for questions about Analyzer see Primus emc218359 - this is a list of most of the Primus solutions

glen

Large IO size - greater than 64KB could indication a backup operation - backups by their nature are generally sequential. The more sequential the IO, the better the cache works.

If you need to determine if IO is sequential or random, there are a number of ways to determine this:

1. If the IO is 100% Reads - look at the Read Cache Hit Ratio - the closer you get to 1 the more sequential the IO. If very sequential than the better pre-fetching works

2. If the IO is 100% Writes - look at Full Stripe Writes - if the number of Full Stripe Writes is the same as Total Write IOPS, then the data is very sequentail and the better the cache will work - you can eliminate the extra parity calculations when using raid 5.

Most of this is explanined in the two Best Practice documents:

EMC CLARiiON Performance and Availability Release 30 Firmware Update Applied Best Practices.pdf

EMC CLARiiON Storage System Fundamentals for Performance and Availability

glen

ABQL is a counter that can be useful if the ABQL is high, response will climb as the i/o waits to be serviced. if there are many host attached to the array it would be worth checking the HBA queue depth setting, 32 is a good starting point.

if the ABQL is partnered with Queue Full conditions then setting the HBA queue depth will certainly help the issue

- you can eliminate the extra parity calculations when using raid 5.

Well.... not entirily true. there's still a write penalty, but it is indeed lower than with random I/O or even with RAID10. With RAID10 the penalty is always 2 for writes, no matter if it's random or sequential. With RAID5 the penalty is 4 for random I/O. For sequential IOs the penalty is 1,25 in a 5 disk RAID5 Raid Group and 1,125 for a 10 disk RAID5 RG.

The dump method will work when we have navi analyzer licensed(nar file) though

we consider a 15K rpm FC disks to be 180 IOPS for ideal calculations. But the actual numbers depends on the actual RD or WR sizes. So if my IO(RD/WR) is always under 4K( example exchange log) then how much IOPS i can expect from the same disk?.

I remember people mentioning they have observed even 300 IOPS in some cases , but not sure how small thier IO size was.

It really varies based on IO size, randomness, etc. The latest Best Practice guide for flare 30 has some more detail on this in the sizing section near the end.

glen

there are a number of factors which affect disk IOPS, not all of which we can detail on a public forum. You can ask for a USPEED rep to run your numbers through a sizing tool which will give you a very good estiamte. But you will have to know your level of sequentiality, read/write mix (what % is reads, what is writes) and predominant IO size.

For example, exchange log is sequential IO, the drives can absorb a lot of sequential small writes as they get bundled up in the cache and executed as a few large writes periodically. Uncached, sequential is also fast as the drives spin pretty quick, as long as you are reading/writing in the same direction they can lay down data prett fast :-)