improve f400 service times

[mohuddle]

Had an event this morning ( application service delayed ) so processing ran into later morning hours, thought I would use SysReporter to to monitor activity.

I'm seeing low utilization in terms of IOPs, but somewhat high service times; 3.2ms to 11.3ms. These normally run 0.6ms to 3.6ms. All in all, 11.3 ms is not bad, right?

Do tools like AO/DO/Compactcpg/Tunesys give improvement in any measurable way? Is it just a matter of more/better/faster hardware?

[mohuddle]

As an add-on to this, how does the 'set size' affect performance? We have 12 cages and I notice a particular CPG that can get quite busy is set to 3+1. Should it be higher to increase the use of spindles across cages? Or is that mostly for protection/recover-ability?

[3ParDude_1]

The data will be striped across the disks in the CPG anyway, making the set size bigger than 3+1 will actually be worse for performance.

I guess the service time figure you gave us is a front end figure. If so I would first of all confirm how the service times from the actual physical disks have changed over the same period. This will help you track down if the slow down is coming from your disks or another component in the system. For example if your disks have also shown an increased service time then it probably is your disks causing the slow down but if this has stayed the same it will give you a clue that it could be some thing like your cache performing worse than before or the front end ports getting stretched.

[mohuddle]

Thanks 3pardude_1. At the 10:11am time sample, Service Time on vlun_perf is 4.8ms - 17.9ms, Looking in at physical 'High-Res PD Performance vs Time' at same time, mostly flat with Service Time range of 4.6ms to 7.8ms .

[RitonLaBevue]

Service Time on front-end port...
You must have a look to your back-end (disks) with System Reporter... Then also have a look to VLun performances if any of them push down the global perf of the array.

[BryanW]

+1 to vlun perf and sorting by VVs, Max 16 and select peak as total_svctms then total_iops, the total_kbps. You should see the offenders and offendees pretty clearly if it a VV util issue.

Also if you have a physical disk breaking bad you can see an overall increase in performance time.
Usually it will predicative fail before you see to much latency, but not always.

Use the PDperf SR graph, compare PDID, Max 16 and select peak as total_svctms

If a wonky disk is the case you will tell pretty quickly as a disk will be noticeably out of lock step of the others. You can then work with support to servicemag the offender out and replace, or do it yourself if that is how you roll.

[mohuddle]

Thanks BryanW, that's good information to have.