Open Stack

A juno feature may help with this, Utilization based scheduling:
https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling

That helps when landing the instance, but doesn't help if utilization
changes /after/ instances have landed, but could help with a resize action
to relocate the instance.


- jlk

On Wed, Apr 22, 2015 at 8:44 AM, Allamaraju, Subbu <subbu at subbu.org> wrote:

> In addition to these factors, collocation happens to be another key source
> of noise. By collocation I mean VMs doing the same/similar work running on
> the same hypervisor. This happens under low capacity situations when the
> scheduler could not enforce anti-affinity.
>
> Subbu
>
> > On Apr 22, 2015, at 5:09 AM, George Shuklin <george.shuklin at gmail.com>
> wrote:
> >
> > 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.shuklin at gmail.com]
> >>> Sent: 21 April 2015 23:55
> >>> To: openstack-operators at 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 at lists.openstack.org
> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150422/5b0c23fa/attachment.html>