[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Memory overcommitment in Xen.





On Mon, Dec 5, 2016 at 7:03 AM, Austin S. Hemmelgarn <ahferroin7@xxxxxxxxx> wrote:
On 2016-12-04 14:21, Carl Schneider wrote:
How Memory overcommitment work in Xen? It is automatically or must be enabled?

Overcommitment is not a feature, but a state of the system. Basically,
things like Ballooning allow you to take away Memory from a domain,
while it "thinks" that it still has it available (From within the
domain, it looks like the balloon driver allocates a big chunk of
memory, as far as I know).
So, if you have e.g. a system with 8GB of memory, and start up 4 domains
(including dom0) that have an maxmem of 2GB, you are not overcommiting,
but use up all your available memory.
Actually, that would be over-committed, and you wouldn't be able to start all the VM's in that situation unless at least one was pre-ballooned (maxmem higher than memory), because you lose part of that 8G to Xen and the hardware (so 8G of physical RAM is actually about 7.95G usable under Xen).

I have a question for you.  I use Xen Orchestra and Xen.  I assume this is a Xen bug but every once in a while, upon domU creation, the creation memory settings will be corrupt.  I get something like this:

Static:  128 MiB/ 2 GiB
Dynamic:  2 GiB/ 4 GiB

This will cause 100% CPU use and a very slow VM.  I have seen corrupt settings like this too:

Static:  128 MiB/ 2 GiB
Dynamic:  2 GiB/ 1 TiB
 
Which is just ridiculous.  I cannot set these settings via command line and it appears to be a bug somewhere but this is not my point.

The question I have is:  what really happens inside of xen when you try and start something like this?


Let us assume that the domains now just needs 1GB, so the ballooning
driver gives some memory "back" to the hypervisor. Now it is possible to
start another domain, but the sum of all maxmems is now bigger than 8GB.
This state is called overcommitment.

Note that this is not only possible with Memory, but also with disk
storage (LVM thin provisioning, e.g.).
It's also possible (and very commonly used) with processors.

My opinion about this: If you do not know the workload of your system
and do not understand the problems of this exactly, do not over-commit
too much and keep an eye on your system. I do not have any experience
with the problems of over-committing, so I can not estimate the risks of it.
In general, you can safely get away with over-committing CPU's.  Most people who aren't hosting providers do this at least some of the time when using Xen (or Hyper-V, or VMWare).  Over-committing disk space is a bit riskier, but generally safe (most things will gracefully handle unexpectedly running out of disk space) as long as you have Domain-0 and the guest domains set up such that unused space gets properly reclaimed (this isn't too hard with PV Linux guest domains, but it is seriously annoying to set up with Windows guests).  Over-committing memory, however, is seriously risky unless you have a well-defined static workload and you have a _very_ good understanding of how it behaves and expects memory to behave.  If you don't get things correct with memory over-commit, you will crash at least a guest domain, and possibly your whole system.



Note that I do not have any noteworthy experience with ballooning or
overcommitting, so if I made a mistake, please correct me.
It may also be possible that I am just plain wrong, too. (Take this as a
disclamer)

Cheers
CRT

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.