Performance By Design

This is final blog post in a series on VMware memory management. The previous post in the series is here : Final Thoughts We constructed and I have been discussing in some detail a case study where VMware memory over-commitment led to guest machine memory ballooning and swapping, which, in turn, had a substantial impact on the performance of the applications that were running. When memory contention was present, the benchmark application executed to completion three times slower than the same application run standalone. The difference was entirely due to memory management “overhead,” the cost of demand paging when the supply of machine memory was insufficient to the task. Analysis of the case study results unequivocally shows that the cost equation associated with aggressive server consolidation using VMware needs to be adjusted based on the performance risks that  can arise when  memory is over-committed.  When configuring the memory on a VMware Host machine, for optimal perfo

This is a continuation of a series of blog posts on VMware memory management. The previous post in the series is  here . Swapping VMware has recourse to steal physical memory pages granted to a guest OS at random, which VMware terms swapping , to relieve a serious shortage of machine memory. When free machine memory drops below a 4% threshold, swapping is triggered.  During the case study, VMware resorted to swapping beginning around 9:10 AM when the Memory State variable reported a memory state transition to the “Hard” memory state, as shown in Figure 19. Initially, VMware swapped out almost 600 MB of machine memory granted to the four guest machines. Also, note that swapping is very biased. The ESXAS12B guest machine was barely touched, while at one point 400 MB of machine memory from the ESXAS12E machine was swapped out. Figure 19. VMware resorted to random page replacement – or swapping – to relieve a critical shortage of machine memory when usage of machine memory exce

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 VMw