Response time = Service time * Queue Length.  So usually high queue lengths will show up in response time.  Here is typically what I look at for the basics.  I drill down into more of the metrics often, but these usually uncover issues which tell me which other metrics I need to look at.  LUN Metrics Response time Read/Write Throughput (I/O) Read/Write Size - Usually large sizes indicate sequential operations (i.e. backups, full table scans, etc) Bandwidth is just I/O * I/O size, so the metric itself isn't too useful.  It usually just reveals the type of I/O really. Average Busy Queue Length - This can reveal host issues (If HBA queue depth is too high then you'll see this number really high).  It also reveals how "bursty" an application is. Forced Flushes/s is also good to check if a particular LUN is having problems.  Disk/RAID Group Metrics Total Throughput (Disk) - If you see the total throughput of an individual disk over around 160 IOPS for a 15k drive (180 is the rule of thumb, but usually very large I/O will max out out around 160 IOPS) It might be time to spread it across more spindles. Compare read/write size to disk/RG to the LUN's read/write size - Larger reads/writes to disk than to LUN are usually good - it means cache is doing what it's supposed to do.  SP Metrics % Dirty Pages % Utilization Check for Queue Full on SP ports Check bandwidth on SP ports
Hello All,  I'm working to build an initial performance review for some CX3-80 arrays.  All of the disks are I've gathered Navisphere Analyzer data for a week and I'm now processing it out.  I'd like to get some feedback on which performance areas some of you use when building baselins.  These are the areas I'm pulling so far:  LUN/RAID Group/Disk/SP Utilization Response Time Total Throughput  At first these seemed like the main areas to focus on, but after reading more on the characteristic definitions, I'm wondering if it's also a good idea to include queue length with response time.  From my initial research and chats with peers, I built the belief that focusing on total I/O was a better metric to collect rather than bandwidth, but now looking back, I'm not sure if that's always correct.  I see value in knowing how many reads and writes are being services in addition to the total I/O, but my fear is that trying to include all of these areas will make any type of performance report too bloated and not practical for anyone to use.  I also realize that values for response time will vary depending on the type of data, application, host, etc, so I'm also not sure how much real value that may be to include.  If some of you are willing, I'd very much like to see what performance areas you think are prudent to include in a general health overview.  Also, I'd be interested to hear about any supplemental software packages you may be using to monitor performance.  Thanks for reading, Lee
Clariion Performance Metrics to Focus On