{"id":722,"date":"2010-10-24T21:30:36","date_gmt":"2010-10-24T20:30:36","guid":{"rendered":"http:\/\/vmdamentals.com\/?p=722"},"modified":"2011-12-29T11:41:17","modified_gmt":"2011-12-29T10:41:17","slug":"vscsistats-into-the-third-dimension-surface-charts","status":"publish","type":"post","link":"https:\/\/www.vmdamentals.com\/?p=722","title":{"rendered":"vscsiStats into the third dimension: Surface charts!"},"content":{"rendered":"

How could I ever have missed it… vscsiStats. A great tool within vSphere which enables you to see VM disk statistics. And not only latency and number of IOPs… But actually very cool stuff like blocksizes, seekdistances and so on! This information in not to be found in esxtop or vCenter performance graphs… So we have to rely on once more on the console…\n<\/p><\/blockquote>\n



\nUPDATE: Available now: vscsiStats in 3D part 2: VMs fighting over IOPS<\/a> !
\nUPDATE2: Build your own 3D graphs! Check out vscsiStats 3D surface graph part 3: Build your own!<\/a>
\n

\nI will not be going into the details of setting up how to use vscsistats. There are plenty of blogposts on that, for example this great post on Gabes Virtual World<\/a><\/p>\n

vscisStats is a REALLY cool tool. Though exciting as vscsistats may be, it is and remains a tool which measures over time and then outputs a number of histograms of a certain virtual disk. All are basically mean values over time.<\/p>\n

Those who have read my performance report on the Sun 7000 storage (see Breaking VMware Views sound barrier with Sun Open Storage<\/a>) will know I am a big fan of surface charts. Basically vscsiStats is a perfect tool for integration into 3D graphs. <\/p>\n

The idea is that vscsistats should be used to create the histograms over let’s say 30 seconds. Then shoot another 30 seconds, then another… After 20 “samples” we put all histograms into a surface area chart and voila! We have disk statistics visible as time passes by.
\n


\nTO THE LAB!<\/strong><\/p>\n

It is once again testing time! After getting the first results out of vscsiStats, I wrote a very basic piece of script to get several measurements right behind each other. Just call it using three parameters (WorldGroupID, HandleID, sampletime):<\/p>\n


\necho Recreating the output file
\nrm -f out1.csv
\ntouch out1.csv<\/p>\n

echo Running stats
\n\/usr\/lib\/vmware\/bin\/vscsiStats -w $1 -i $2 -s
\nfor i in $(seq 1 1 21)
\ndo
\n   sleep $3
\n   \/usr\/lib\/vmware\/bin\/vscsiStats -w $1 -i $2 -p all -c >>out1.csv
\n   \/usr\/lib\/vmware\/bin\/vscsiStats -w $1 -i $2 -r
\ndone
\n\/usr\/lib\/vmware\/bin\/vscsiStats -w $1 -i $2 -x<\/code>\n<\/p><\/blockquote>\n

EDIT<\/strong>: Thanks to NiTRo (from www.hypervisor.fr<\/a> ) for the edit in the “for” command to get it ESXi compatible!<\/em><\/p>\n



\nBasically this script starts measurements on a single virtual disk, after 30 seconds the data is added to a file in the csv format and the statistics get a reset. This process is repeated 21 times. So I end up with 21 sets of histograms, each 30 seconds apart.<\/p>\n

Now the magic Excel comes in. Drawing the histograms right after each other makes them interconnect-able using a surface chart.
\n


\nENOUGH TALK… ON TO THE OUTPUT!<\/strong><\/p>\n

Once the Excel is built, you can quickly import different vscsiStats outputs into the Excel form, and the 3D graphs will immediately show you the measured values in 3D! I have used standard colors for different graphs: blue for I\/O, green for READS and red for WRITES. Check it out:<\/p>\n

\"Example<\/p>\n

As you can see, through time there is a very clear “edge” along the +1 line. This indicates linear I\/O. Cool right! On to more examples…
\n


\nEXAMPLE 1: vCenter Bootdisk<\/strong><\/p>\n

This is what a vCenter server bootdisk is doing all day:<\/p>\n

\"vCenter
\nBasically the disk is idle for reads, but every 60 seconds there is a read burst of 8192 byte blocks, between 500 and 900 reads are performed.
\n

\n\"vCenter
\nWrites are significantly less, but more regular. Most writes appear to be 4096 byte blocks, some smaller.
\n


\nSo how about randomness of these reads\/writes? Well, check this out:
\n\"vCenter
\n… You can clearly see the three recorded bursts laying in the graph. These reads are pretty much random, since almost all have a distance of around 1000 logical blocks.
\n

\n\"vCenter
\nWrites are more of a mishmash. Most writes are fully random (the edges around +500.000 and -500.000), but some of the writes are linear (the peaks in the center of the graph). Especially the peak in the center of the graph at 60 seconds. Now check out the previous writes graph at 60 seconds: There is a peak visible there also, at a very small blocksize of only 1024 byte blocks. My guess would be the system (for some reason) decided to write many small blocks sequentially to disk. This definitely shows the power of vscsiStats in 3D: in a single large data fetch and a single histogram this behavior would have been missed!
\n


\nEXAMPLE 2: Streaming a DVD from a fileserver<\/strong><\/p>\n

Let’s see what happens on a virtual disk which is streaming a DVD:
\n\"Watching
\nWhen streaming data from a file server you can see several block sizes are used. Peaks are visible at 4096, 16384 and 65536, exactly 4K, 16K and most at 64K blocks. It appears the blocks are neatly sized as-needed. I’d expect the reads to be sequential, but how sequential are they really?
\n

\n\"Is
\nHmm. The distance graph shows that there is a massive linear component (edge in the center of the graph at +1). But there are also two edges visible, one at -128 and one at +128 logical blocks.<\/p>\n




\nEXAMPLE 3: Large file reading and writing<\/strong><\/p>\n

Another example is heavy file writing and reading. In this example, I use my file server to copy a large file back and forth a few times between two virtual disks using a batch file:
\n

\n\"I\/O
\nThe file server is busy busy busy… I see a constant I\/O activity at 64K blocks…
\n

\n\"Reads
\nHere you can see the reads… It now becomes clear the server reads, then appears to wait, then reads again.
\n

\n\"Writes
\nLooking at the writes we see the same behavior, but exactly when the reading is idle. Bingo, my batch file does writes-then-reads-then-writes-then-reads-then-writes…
\n

\n\"Read
\nNot much exciting to see in the read distance… reads are 100% sequential.
\n

\n\"Write
\nWrites are a 100% sequential as well…
\n

\n\"Read
\nRead latency is at a very stable 5 [ms]…
\n

\n\"Write
\nUhm! Write latency is around 50 [ms]. It is apparent my storage device is not the fastest around (anyone got an unused EMC AX4-5 somewhere? \ud83d\ude09 )
\n

\n\"Outstanding
\nNow this one is funny… Because the write latency is much higher, so are the number of outstanding I\/Os for writes… In the combined I\/O graph (blue!) it is clearly visible.<\/p>\n




\nEXAMPLE 4: Generating a random read\/write using IOmeter<\/strong><\/p>\n

Just because I can… I decided to run an IOmeter load on 4K blocks, 50% reads 50% writes, 100% random. This is what I got:
\n\"IOmeter
\nInterestingly, IOmeter is not showing a sustained I\/O bandwidth, probably because I choose to have no outstanding I\/Os in this test. All performed I\/Os are neatly at 4096 byte blocks though, as specified within IOmeter.
\n

\n\"IOmeter
\nThe read distance is exactly what was to be expected: at 50% sequential and 50% random, the edges in the center and in the corners are clearly visible.
\n

\n\"IOmeter
\nFor writes, the same story as for the reads: at 50% sequential and 50% random this is expected behavior.
\n

\n\"IOmeter
\nWrite Latency is low. This is probably because the number of outstanding I\/Os was set to zero, effectively not performing writes if another write is pending. As a result, latency in writes is low in this test.
\n

\n\"IOmeter
\nReads are more of a mixed bag: Some reads appear to finish quicker than other, it is either 0,5 [ms] or 10[ms]. This is probably due to the fact that 50% of the reads are performed sequential, 50% is random (slower). Cool!
\n


\nEXAMPLE 4b: Example 4, but with 12 outstanding I\/O’s<\/strong><\/p>\n

I just HAD to run one other test! It is basically the same test as above, but now I tell IOmeter to use up to 12 outstanding I\/O’s:
\n

\n\"IOmeter
\nNow that we allow some I\/O to be outstanding, you can clearly see much more data is moved, and also in a more regular fashion when compared to example 4.
\n

\n\"IOmeter
\nLooking at the outstanding reads, we see that the virtual disk actually is crammed with reads: At almost all times it has 12 reads outstanding (IOmeter just keeps filling the buffer)
\n

\n\"IOmeter
\nIn writes, we see less outstanding I\/O’s. Really up to 12 outstanding, but most of the time there are less outstanding I\/O than the maximum configured.
\n


\nCONCLUSION<\/strong><\/p>\n

The vscsiStats command is a really really great tool to examine disk-workloads on virtual servers. From there on you could potentially optimize your stripe\/segment sizes on storage arrays, for example when you are tuning RAID5 sets for optimizing writes (also see Throughput part2: RAID types and segment sizes<\/a>“). <\/p>\n

But adding the third dimension gives an insight about varying behavior through time. Not always needed (like some VMs which perform very steady through time), but especially when workloads vary on a virtual disk it might be worthwhile to look at things with a little more depth! <\/p>\n","protected":false},"excerpt":{"rendered":"

How could I ever have missed it… vscsiStats. A great tool within vSphere which enables you to see VM disk statistics. And not only latency and number of IOPs… But actually very cool stuff like blocksizes, seekdistances and so on! This information in not to be found in esxtop or vCenter performance graphs… So we […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[77,5],"tags":[120,80,122,123,121,632,119,99],"class_list":["post-722","post","type-post","status-publish","format-standard","hentry","category-storage","category-vmware","tag-disk-io","tag-latency","tag-lbn","tag-lbns","tag-seek-distance","tag-vmware","tag-vscsistats","tag-vsphere"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=\/wp\/v2\/posts\/722","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=722"}],"version-history":[{"count":80,"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=\/wp\/v2\/posts\/722\/revisions"}],"predecessor-version":[{"id":3575,"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=\/wp\/v2\/posts\/722\/revisions\/3575"}],"wp:attachment":[{"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=722"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vmdamentals.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}