High "Frontend Read Latency" on DiskGroup

[AdWi]

Hi,

I`m having some strange issue.

When going through VSAN Performance I have noticed very high Frontend Read Latency on Disk Group on host level (actually on all DG in cluster). However there is no outstanding latency on all other levels - Cluster level (Virtual SAN - Backend, VM consumption), Host level (VM consumption, Virtual SAN Backend, Virtual SAN Disk).

Virtual SAN Disk Group

As you can see the values are definitely to high.

Here is Virtual SAN Backend on host level for comparison:

And Virtual SAN Disk level:

And Virtual SAN VM consumption:

The VSAN is 6.2 in all flash with Dedup and Compression.

Fortunately we haven`t received any complains so far.

What can be a reason for such behavior?

Thanks

[mhampto]

The Frontend (Guest) Latency graph shows vSAN disk group (Cache tier disk) Frontend (guest) latency. Frontend Read Latency Metrics displays the vSAN disk group (cache tier disk) Frontend read latency. For more information, see https://kb.vmware.com/s/article/2144493?language=en_US

[AdWi]

Thanks, but checking VMware KB was first thing I did. Their explanation does not tell me anything.

[eode · Accepted solution]

Hi.

Was waiting for my SR to be closed before replying here; this is a bug in reporting. Same "latency" was seen in both Web Client (under %host% > Monitor > Performance > Virtual SAN - Disk Group > "Frontend(Guest) Latency", and in VSAN Observer (on LSOM/lsomhost, that's VSAN Disks (deep-dive) > %host% > Host disk-layer aggregate stats > Full graphs > Look in the first graph - latency). Value was reporting around 200.00 - 500.00, when it should have been 0.2 - 0.5.

Good news is that it's resolved in the latest 6.0 U3-release (build 6921384).

From the release notes / VMware Knowledge Base​

"The Host disk-layer aggregate stats full graphs view under the vSAN Disk (deep-dive) tab might report wrong latency values, because the latency values are generated in nanoseconds, but wrongly interpreted as milliseconds."

Nanoseconds.. well.. based on the numbers (500 to 0.5) it's microseconds. Anyways, it's now fixed! :-).