0

So I am running a bunch of guests on a bunch of servers and currently my "standard" guest partitioning goes like this:

  1. 1GB for /boot
  2. 4 - 8 GB for swap
  3. the rest for /

I allocate various amounts of RAM to each guest, depending on the needs of the app running within it. Swap too depends on the app.

The swap is there for the times when some operation goes beyond what it was designed for and uses more RAM that there is.

However,this seems quite wasteful to me: I'm using 4 - 8GB of disk space for each guest just because it might need it a couple of times per day? Considering that those guests are typically 20GB, hosting code mostly (database servers are separate), that's quite a percentage.

I just spent reading the posts about this on various stack exchange sites, but haven't found any trace of a more elegant solution. By "elegant solution" I mean some sort of swap space sharing among clients.

The suggested approaches (that I saw) are:

  1. use swap in guest
  2. overcommit the host

Alternatively, the best approach that already works (but wasn't suggested all that often) seems to be memory ballooning (only works on Linux guests, but that's fine) with some sort of real-time monitor / adjustment agent that would allocate RAM on demand.

So, what is the best approach to take these times?

2 Answers 2

2

I suggest leaving things as simple as possible: memory management is a complex topic by itself, and the last thing you want is a guest crashing due to premature/unnecessary optimization.

2 GB of swap space is a reasonable starting point for small guests, with 4/8 GB adequate for bigger ones. You can use thin volumes for swap, but at these small sizes it should not matter much.

-1

Remove in-guest paging spaces. Allocate guest memory to not overcommit host memory. Get more memory if necessary

Optionally, enable kernel same-page merging (KSM) to get some deduplication.


Paging space is supposed to be inexpensive to justify being 100x slower than DRAM. In my opinion, if it is expensive and slower and requires some thin provisioning scheme to have enough, it is not worth keeping.

Overcommit is risky in that if use exceeds expectations, performance will be terrible. Or worse, annoy the OOM killer. By monitoring usage you could take action before OOM, but do you want to spend the effort to save a bit on DRAM costs?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .