This post is more than 5 years old
58 Posts
0
799
VPLEX Monitor counter units - KB/sec
I am trying to monitor writes to a virtual volume in order to calculate WAN bandwidth utilization after mirroring. I'm confused on the units being reported, though.
I'm setting up the virtual-volume.writes monitor every 5 seconds and a file-sink. Then I'm using the CSV output and charting with Excel. The data collect and charting works great. However the units reported are supposedly Kilobytes per second.
What does this mean exactly for a 5 second (or 30 second, or 5 minute) collect? Is this total number of Kilobytes written throughout the collect period? Is this an average KB/sec write rate throughout the period? Is this the maximum KB/sec write rate during the time period? It is odd to me because you don't generally have a per second write rate in a cumulative counter.
Thanks for any clarification on these units.
rzero
58 Posts
0
November 3rd, 2014 07:00
I ran a 1 second and 30 second write monitor on the same volume and compared stats. It appears that this measurement is the average write rate over the specified period.
For a given 30 second interval using the 1 second file data, the peak KB/sec rate was 4412, the total transferred was 20176, and the average was 20176/30 or 672.53333. The 30 second file shows a rate of 673 for this interval.
So for calculating average utilization a long interval may work but for peak utilization the shortest interval possible would be better.
garyo
89 Posts
0
November 4th, 2014 12:00
Hi raid-zero,
Yes, that is correct as you've discovered, the rate that gets reported is the average over the period.
The VPLEX perpetual monitors are recorded every 30 seconds. You could create a custom monitor that has a higher polling frequency. I'd recommend not going any lower than 5 seconds. (1 second is possible, but I would say is a bit overkill.)
You can also observe updates via the Unisphere GUI dashboard, it updates every 5 seconds.
If you want to see raw byte counts, then your only option is to subscribe to the SNMP performance stats.
Thanks,
Gary