HPE Storage Users Group
https://3parug.net/

Doubt about the output or statvv
https://3parug.net/viewtopic.php?f=18&t=3400
Page 1 of 1

Author:  RVilca [ Fri May 15, 2020 12:54 pm ]
Post subject:  Doubt about the output or statvv

Hi,
I have a 3PAR 7400c array, 3.2.2 MU6
I have a doubt about the output of statvv. When I see the output for some VVs with little or no load, in some moments I see the service time with a high value (for example, 180), I/O per second = 0, KB per sec = 1
Therefore, when I implement alert threshold reports, this VV is shown in the report, I think incorrectly.
How could it be explained that there is an service time so high, while the IO is 0 ?

Please give me some guidance on this behavior

Regards,
Roger

Author:  MammaGutt [ Fri May 15, 2020 12:59 pm ]
Post subject:  Re: Doubt about the output or statvv

I usually ignore all values with less than 10 IOPs.

Another question, why do you look at statvv? Isn't statvlun more interesting?

Author:  RVilca [ Mon May 18, 2020 11:25 am ]
Post subject:  Re: Doubt about the output or statvv

Hi,
I am using statvv because statvlun is showing a more extended output due I have a cluster vmware and one VLUN is presented to many hosts. I amlookin for an acumulative I/O for a particular VV and not per VLUN.
Please let me know if you know other advantages of using statvlun above statvv
Thanks

Author:  MammaGutt [ Mon May 18, 2020 11:51 am ]
Post subject:  Re: Doubt about the output or statvv

RVilca wrote:
Hi,
I am using statvv because statvlun is showing a more extended output due I have a cluster vmware and one VLUN is presented to many hosts. I amlookin for an acumulative I/O for a particular VV and not per VLUN.
Please let me know if you know other advantages of using statvlun above statvv
Thanks


I think you got it wrong. One VLUN is one path from one volune to one host. Statvlun will also account for latency in the SAN and basically be the best representation the 3PAR can do of what the host experiences. If statvlun is high, then it is a good time to start looking at statvv to see if the latency was already there when the IO left the 3PAR or if it got somewhere on the SAN. In a clustered or virtualized environment statvlun will also help you see if you have a problem with one host or path accessing the volume. If 10 VMs on 10 different hosts do 1000 IOPs each on one volume, 9 of those have 0.5msec latency, the 10th have 15.5msec. Statvv will show nothing wrong, statvlun -vvsum will show 2msec latency and statvlun (with or without -hostsum) will show you that you have one bad egg in the mix.

I'm also very unsure if statvv will count "backend traffic" like reclaim and defrag (I know it shows T10 unmap), but if it does it will show traffic that doesn't come from any host.

Author:  RVilca [ Mon May 18, 2020 3:01 pm ]
Post subject:  Re: Doubt about the output or statvv

Hi,
Thanks for your comment.

I am comparing the output of statvv and statvlun -vvsum and I see that statvlun has more service time and more qlen (por example service time = 25 and qlen = 78).
I know that one rule of thumb is try to keep the service time below 20, but I don't know what does it mean qlen and if it is possible to change the queue length.

you could say is there a contention at the server level ?

Regards.

Author:  MammaGutt [ Mon May 18, 2020 11:53 pm ]
Post subject:  Re: Doubt about the output or statvv

Personally I think 20msec is too much.

In a non-replicated environment I wouldn't want to see the average go very much above 10msec for fc and 15msev for NL. This is of course dependent of your environment but both a FC and NL drive should be able to service an IO in less than 10msec. Adding to the fact that most/all writes should hit cache with a sub msec latency, 20msec becomes a lot.

Qlen on 3PAR doesn't display the total length of the queue, it tell you how much is in the queue. Anything in que will impact latency as it tells you that the 3PAR wasn't ready to service the IO.

If statvlun -vvsum is significant higher than statvv (and I would say that 1-2 msec is very significant here, I think you have a problem outside the 3PAR. This is the time where you remove the -vvsum and start looking at all VLUNs for that VV to see if it is a general problem or if it is a problem with paths from one node, paths on one port, paths to one host or paths sharing the same ISL somewhere in your fabric.

Are you using FC or iSCSI? And what type of array (and config) you got?

Author:  RVilca [ Tue May 19, 2020 5:26 pm ]
Post subject:  Re: Doubt about the output or statvv

Hi,
I noticed that at moment of high load the time of reading is much more that time of writing, so I am considering to enable the Adaptive Flash Cache Option. We use SSD, FC and NL disk, but we have contention major in FC and the combination of FC enabled with tier 0. I have not experience with Adaptive Flash Cache and the implications in the current configuration. We have 2 arrays 3PAR 7400 FC and the hosts are connected by FC using SAN switches. We have two fabrics and the arrays are connected using ISL with a distance of several km using dark fiber. I haven't seen that the replica could be the problem (we use Remote Copy but not for LUNs with latency).
On the other hand the hosts are mostly blades inside chassises connected to SAN switches and in an vmware enviroment.

Regards.

Author:  MammaGutt [ Wed May 20, 2020 1:53 am ]
Post subject:  Re: Doubt about the output or statvv

RVilca wrote:
Hi,
I noticed that at moment of high load the time of reading is much more that time of writing, so I am considering to enable the Adaptive Flash Cache Option. We use SSD, FC and NL disk, but we have contention major in FC and the combination of FC enabled with tier 0. I have not experience with Adaptive Flash Cache and the implications in the current configuration. We have 2 arrays 3PAR 7400 FC and the hosts are connected by FC using SAN switches. We have two fabrics and the arrays are connected using ISL with a distance of several km using dark fiber. I haven't seen that the replica could be the problem (we use Remote Copy but not for LUNs with latency).
On the other hand the hosts are mostly blades inside chassises connected to SAN switches and in an vmware enviroment.

Regards.


The reason for higher read latency is that write will usually go straight to cache (as long as there is free pages to be used) while read usually has to go down to the storage media.

If you have available SSD capacity, using it for AO is in my experience the best use in 99 out of 100 cases.

If your FC is overloaded, then that will usually impact everything. Drives are to busy to destage write cache so there is no free cache pages for new writes.

If would look at AO and the output from srrgiodensity to understand which volumes are the heavy hitters and how much of that data is active.

Author:  RVilca [ Thu May 21, 2020 5:06 pm ]
Post subject:  Re: Doubt about the output or statvv

Thank you very much for your help.

Regards.

Page 1 of 1 All times are UTC - 5 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/