Over a million developers have joined DZone.
Platinum Partner

Dynamic Memory – Not Your Father’s Memory Overcommit: Part 3

· DevOps Zone

The DevOps Zone is brought to you in partnership with Librato.  Check out Librato's whitepaper on Selecting a Cloud Monitoring Solution.

Part 3 of our “20+ Days of Server Virtualization” series is about Dynamic Memory in Hyper-V.  As the title suggests, this is not your Father’s Memory Overcommit.

“Memory Overcommit?  Isn’t that a VMware capability?”

In the context of virtualization, yes.  (It may be something addressed in the field of Neuroscience, but I’m no rocket scientist…)

Before we talk about it, let’s take a look at the word “Overcommit” (from The Free Dictionary):

O·ver·com·mit (vr-k-mtv. o·ver·com·mit·tedo·ver·com·mit·tingo·ver·com·mits v.tr.

  1. To bind or obligate (oneself, for example) beyond the capacity for realization.
  2. To allocate or apportion (money, goods, or resources) in amounts incapable of replacement.


  1. To be or become overcommitted.

That phrase “beyond the capacity for realization” is important.  To overcommit memory means to obligate more memory be used than the capacity we actually physically have. 

“Is that a good thing?”

It can be, if, in the case of the consolidation ratios of virtual machines on a physical host, it’s more important for you to pack more onto a box than it is to get decent performance out of those virtual machines.

“Dynamic Memory” is Microsoft’s solution (in Hyper-V) to do something similar.  But in this case, Microsoft does not overcommit.  By contrast, it allocates memory to or from VMs sharing a virtualization host based on the memory demand of the VMs. 

Today in Part 3, my friend Dan Stolts expands on this definition and these technologies for us.



Published at DZone with permission of Kevin Remde , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}