Continuing a series of blog posts on “expert” computer Performance rules, I am reminded of something Captain James T. Kirk, commander of the starship Enterprise, once said in an old Star Trek episode: “There’s a lot more to running a starship than answering a lot of fool questions.”Star Trek, The Original Series. Episode: The Deadly Years. Season 2, Episode 12. See http://tos.trekcore.com/episodes/season2/2x12/captioninglog.txt. For some reason, the idea that the rote application of some set of rules derived by a domain “expert” can suffice in computer performance analysis has great sway. At the risk of beating a dead horse, I want to highlight another example of a performance Rule you are likely to face, and, in the process, discuss why there is a whole lot more to applying it than might be obvious at first glance. There happens to be a lot more to computer performance analysis than the rote evaluation of some set of well-formed performance rules. It ought to be apparent by now that I …
To assess the overall impact of the VMware virtualization
environment on the accuracy of the performance measurements available for
Windows guest machines, it is necessary to first understand how VMware affects
the clocks and timers that are available on the guest machine. Basically,
VMware virtualizes all calls made from the guest OS to hardware-based clock and
timer services on the VMware Host. A VMware white paper entitled “Timekeeping in VMware
Virtual Machines” contains an extended discussion of the clock and timer
distortions that occur in Windows guest machines when there are virtual machine
scheduling delays. These clock and timer services distortions, in turn, cause
distortion among a considerably large set of Windows performance counters,
depending on the specific type of performance counter. (The different types of
performance counters are described here…
This is a continuation of a series of blog posts on VMware memory management. The previous post in the series is here.
Ballooning Ballooning is a complicated topic, so bear with me if this post is much longer than the previous ones in this series.
As described earlier, VMware installs a balloon driver inside the guest OS and signals the driver to begin to “inflate” when it begins to encounter contention for machine memory, defined as the amount of free machine memory available for new guest machine allocation requests dropping below 6%. In the benchmark example I am discussing here, the Memory Usage counter rose to 98% allocation levels and remained there for duration of the test while all four virtual guest machines were active.
Figure 7, which shows the guest machine Memory Granted counter for each guest, with an overlay showing the value of the Memory State counter reported at the end of each one-minute measurement interval, should help to clarify the state of VMware memory-managemen…