One of the unsung advantages of LXC and OpenVZ, is that the disk cache is unified.
Full virtualization like KVM or VMWare, require you to give each VM extra RAM for use with disk cache. For instance, if you had a typical set of processes that used 1.5GB, and you gave it 1.7GB, that would hardly be enough, as you want more than 200MB of disk cache.
Under LXC and OpenVZ, any unused RAM becomes globally available for disk caching, giving a decent performance boost and further reducing the resouce commitments per-VM.
One example: a customer had some lousy queries in their SQL, but they really needed to have a good demo of their site. We moved them to a 32GB RAM system and gave the container 8GB.
As a result, nearly the entire 20GB database (or at least the parts that were needed), got loaded into the disk cache after the first batch of queries were run. It was enough to get them over the hump (they later figured out the nasty SQL that was getting them in trouble) and they had a good demo. After that, we live-migrated back to their regular server.
I get the flexibility that gives you, but in that instance you've evidently got a 32GB machine sitting there, unused. For my money it's just as valid to move their guest to the 32GB machine, balloon up to allocate the space and allow the guest to use the extra space as disc cache as required, then balloon down afterwards and migrate off as normal.
True, but then the live-migrate feature would not be possible. Also, even in Xen, the ballooning can only be done in a range (I think not quite 4 times), so you can't set up 1GB and then balloon to 28GB, then go down to 1GB again.
> True, but then the live-migrate feature would not be possible.
Why not?
> Also, even in Xen, the ballooning can only be done in a range (I think not quite 4 times), so you can't set up 1GB and then balloon to 28GB, then go down to 1GB again.
Full virtualization like KVM or VMWare, require you to give each VM extra RAM for use with disk cache. For instance, if you had a typical set of processes that used 1.5GB, and you gave it 1.7GB, that would hardly be enough, as you want more than 200MB of disk cache.
Under LXC and OpenVZ, any unused RAM becomes globally available for disk caching, giving a decent performance boost and further reducing the resouce commitments per-VM.
One example: a customer had some lousy queries in their SQL, but they really needed to have a good demo of their site. We moved them to a 32GB RAM system and gave the container 8GB.
As a result, nearly the entire 20GB database (or at least the parts that were needed), got loaded into the disk cache after the first batch of queries were run. It was enough to get them over the hump (they later figured out the nasty SQL that was getting them in trouble) and they had a good demo. After that, we live-migrated back to their regular server.