Yes, it really depends on the used backing technique. We using SSDs and raw images, so IO is not an issue.

But memory is more important: if you lack IO capability you left with slow guests. If you lack memory you left with dead guests (hello, OOM killer).

BTW: Swap is needed not to swapin/swapout, but to relief memory pressure. With properly configured memory swin/swout should be less than 2-3.

On 04/22/2015 09:49 AM, Tim Bell wrote:
I'd also keep an eye on local I/O... we've found this to be the resource which 
can cause the worst noisy neighbours. Swapping makes this worse.

Tim

-----Original Message-----
From: George Shuklin [mailto:george.shuk...@gmail.com]
Sent: 21 April 2015 23:55
To: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] over commit ratios

It's very depend on production type.

If you can control guests and predict their memory consumption, use it as base
for ratio.
If you can't (typical for public clouds) - use 1 or smaller with
reserved_host_memory_mb in nova.conf.

And one more: some swap sapce is really necessary. Add at least twice of
reserved_host_memory_mb - it really improves performance and prevents
strange OOMs in the situation of very large host with very small dom0 footprint.

On 04/21/2015 10:59 PM, Caius Howcroft wrote:
Just a general question: what kind of over commit ratios do people
normally run in production with?

We currently run 2 for cpu and 1 for memory (with some held back for
OS/ceph)

i.e.:
default['bcpc']['nova']['ram_allocation_ratio'] = 1.0
default['bcpc']['nova']['reserved_host_memory_mb'] = 1024 # often
larger default['bcpc']['nova']['cpu_allocation_ratio'] = 2.0

Caius


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply via email to