<div dir="ltr">A juno feature may help with this, Utilization based scheduling:<div><a href="https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling">https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling</a><br></div><div><br></div><div>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.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr">- jlk</div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Apr 22, 2015 at 8:44 AM, Allamaraju, Subbu <span dir="ltr"><<a href="mailto:subbu@subbu.org" target="_blank">subbu@subbu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Subbu<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Apr 22, 2015, at 5:09 AM, George Shuklin <<a href="mailto:george.shuklin@gmail.com">george.shuklin@gmail.com</a>> wrote:<br>
><br>
> Yes, it really depends on the used backing technique. We using SSDs and raw images, so IO is not an issue.<br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
> On 04/22/2015 09:49 AM, Tim Bell wrote:<br>
>> 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.<br>
>><br>
>> Tim<br>
>><br>
>>> -----Original Message-----<br>
>>> From: George Shuklin [mailto:<a href="mailto:george.shuklin@gmail.com">george.shuklin@gmail.com</a>]<br>
>>> Sent: 21 April 2015 23:55<br>
>>> To: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
>>> Subject: Re: [Openstack-operators] over commit ratios<br>
>>><br>
>>> It's very depend on production type.<br>
>>><br>
>>> If you can control guests and predict their memory consumption, use it as base<br>
>>> for ratio.<br>
>>> If you can't (typical for public clouds) - use 1 or smaller with<br>
>>> reserved_host_memory_mb in nova.conf.<br>
>>><br>
>>> And one more: some swap sapce is really necessary. Add at least twice of<br>
>>> reserved_host_memory_mb - it really improves performance and prevents<br>
>>> strange OOMs in the situation of very large host with very small dom0 footprint.<br>
>>><br>
>>> On 04/21/2015 10:59 PM, Caius Howcroft wrote:<br>
>>>> Just a general question: what kind of over commit ratios do people<br>
>>>> normally run in production with?<br>
>>>><br>
>>>> We currently run 2 for cpu and 1 for memory (with some held back for<br>
>>>> OS/ceph)<br>
>>>><br>
>>>> i.e.:<br>
>>>> default['bcpc']['nova']['ram_allocation_ratio'] = 1.0<br>
>>>> default['bcpc']['nova']['reserved_host_memory_mb'] = 1024 # often<br>
>>>> larger default['bcpc']['nova']['cpu_allocation_ratio'] = 2.0<br>
>>>><br>
>>>> Caius<br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-operators mailing list<br>
>>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>