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
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
@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
.
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
We had this discussion at the Ops Mid-Cycle meetup. I think the general
consensus was 0.9 for memory. if you're running Ceph OSD's on the node
you'll almost certainly want to reserve more than a gig for it and the OS.
for CPU there was a wide range of ideas and it mainly depended on use-case.
If
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
