service time for disk/LUN

In HP-UX the sar command returns a service time and that could be a value blended across metas as the particular disk/ctd might be a combination of metas.

We manage to get the service time for processes using the help of extract commands.

is there a way to measure the service time(average service time) for a particular LUN/disk from SAN side.

Responses(4)

bodnarg

385 Posts

0

March 5th, 2008 05:00

If you use WLA the answer is yes. Simply open up the Symmetrix and under the Devices folder select "sampled average read time (ms)" and "sample average write time (ms)" to get what you want.

Not sure if there is a nice way to do this using symstat or any other tools if WLA is not available to you.

You could also always get your local CE to generate a report against your Symmetrix/DMX - but this is obviously only good for a point in time check.

B

brutus333

3 Posts

0

March 20th, 2008 08:00

Actually we are using WLA but we cannot use the metrics you suggested.
The metric value is somewhere arround 2e9 and 2e10 ms which I supposed are values far too high to be realistic.
Do you have any explanation on this?

tonydcdi-ymiT1

70 Posts

1

March 20th, 2008 10:00

If this is control center 6.0 then there is a patch for the exponential issue. CC_4072 is the patch number and must be applied to all Symmetrix and SDM agents. The next day you should see the exponents be normalized

bodnarg

385 Posts

1

March 20th, 2008 10:00

Not knowing what version of ECC/WLA or the microcode levels for the DMX/Symmetrix in question, but I have seen issues in the past around this particular metric that required a) a WLA patch and b) a microcode patch to resolve. I can not recall the exact details (microcode or WLA versions) but it was definitely at some level of ECC 5.2 with a DMX-3000 series array.

Also, I have seen cases where for LUNs with very low I/O this metric may present a garbage number. This is true for tools like sar as well - general rule of thumb that has worked for me in the past is to throw-out any service time statistics for very low I/O volumes.

So no concrete explanation - but two possible explanations. If you are very recent versions of code and have good sustained I/O then I'd suggest opening a case with EMC to get them to resolve the issue.

View All

No Events found!