fuel-dev team mailing list archive

[Vladimir Kuklin <vkuklin@xxxxxxxxxxxx>]

Guys

We've splitted solving of this issue into two parts:
1) there is a review which fixes the fact that we do not have scheduler
filters configured https://review.openstack.org/#/c/90106
2) all other improvements should be discussed in the blueprint
https://blueprints.launchpad.net/fuel/+spec/scheduler-config-improvements

Thus, I am closing this thread. All other discussions regarding Fuel should
be performed in openstack-dev ML with '[Fuel]' prefix in email subject.


On Sun, Apr 6, 2014 at 12:38 AM, Andrey Korolev <akorolev@xxxxxxxxxxxx>wrote:

> On Sun, Apr 6, 2014 at 12:24 AM, Roman Sokolkov <rsokolkov@xxxxxxxxxxxx>
> wrote:
> >
> > Andrey,
> >
> > What i know:
> >
> > KVM not maps directly vRAM to physical.So VM will use just as much as it
> > needs.
> Yes, true for Linux VMs, false for Windows - they trying to allocate
> all dedicated memory by writing zeros at the very beginning. Anyway,
> on long-running periods even Linux VM will allocate all available RAM.
> Then, even if host evict some RAM pages to swap, they will remain
> in-RAM for guest OS causing long scheduler lockups on operations with
> chunks placed to the swap by host. I propose, without any kind of
> resource allocation/management in nova, simple approach, like ashes to
> ashes, dust to dust - do NOT push VM` memory to the swap, instead add
> large swap partition if necessary and introduce it to the VM. Do not
> make any kind of memory overcommit, even with KSM in place, metrics
> from KSM are very rough and not applicable even between two physical
> hosts with same workload, KSM/UKSM behaviour is indeterministic.
>
> > Red Hat recommends to make swap partition with specific size to be
> protected
> > from out of memory cases.
>
> As I said before it will thrash VM` performance for sure. I am not
> very familiar with RHEV resource allocation options, but for such
> "zero-effort-to-make-it-useable" resource police as appeared in
> current Nova, that`s BS recommendation. Can be true for very specific
> and quiet workloads with low memory page eviction rate, but in common
> it is not :). One can adjust oom_score and live with let-it-fail
> approach for VMs, but for most users there is no point too.
>
> >
> > (0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size
> >
> > I think it is reasonable solution, because most of the loads are far from
> > 100%. But i agree in case if 100% load applications it's reasonable to
> make
> > it <=1.
> >
> > Thanks
> >
> >
> >
> > On Sat, Apr 5, 2014 at 12:42 AM, Andrey Korolev <akorolev@xxxxxxxxxxxx>
> > wrote:
> >>
> >> Just a small question - how the hell memory overcommit can be higher
> >> than 1? This will result in OOM and continuous weird behavior as soon
> >> as enough number of VMs will be launched.
> >>
> >> On Sat, Apr 5, 2014 at 3:02 AM, Roman Sokolkov <rsokolkov@xxxxxxxxxxxx>
> >> wrote:
> >> > Just small update about overcommit ratios
> >> >
> >> > As recommended by Red Hat
> >> > vCPU/CPU (cpu_allocation_ratio) = 5 (default 16)
> >> > vRAM/RAM (ram_allocation_ratio) = 1.5
> >> >
> >> > Thanks.
> >> >
> >> >
> >> >
> >> > On Fri, Apr 4, 2014 at 1:04 PM, Roman Sokolkov <
> rsokolkov@xxxxxxxxxxxx>
> >> > wrote:
> >> >>
> >> >> Folks,
> >> >>
> >> >> Any updates on that?
> >> >> Customers that run Fuel for production exactly need finely tuned
> >> >> scheduler.
> >> >> My two latest projects were affected by default "RAW" scheduling.
> >> >>
> >> >> Thank you.
> >> >>
> >> >>
> >> >> On Fri, Mar 21, 2014 at 7:18 AM, Bogdan Dobrelya
> >> >> <bdobrelia@xxxxxxxxxxxx>
> >> >> wrote:
> >> >>>
> >> >>> On 03/21/2014 03:04 PM, Dmitry Ukov wrote:
> >> >>> > Core and Disk  filters should be enabled (they are disabled by
> >> >>> > default)
> >> >>> > in order to avoid compute node oveloading
> >> >>> > - cpu_allocation_ratio=1.0 - was customer requirement. I think
> 16.0
> >> >>> > is
> >> >>> > way to big over commit ratio (potentially 16 vms on 1 core). I
> would
> >> >>> > say
> >> >>> > 2.0 or 3.0 will be reasonable here.
> >> >>> > - disk_allocation_ratio=1.0 - it is unsafe to over commit disk
> >> >>> > - ram_allocation_ratio=1.0 - this was customer requirement.
> Actually
> >> >>> > we
> >> >>> > can use default value here. (AFAIR default is 1.5 )
> >> >>> > - ram_weight_multiplier=0.0 and scheduler_host_subset_size=30 will
> >> >>> > help
> >> >>> > us to get random VMs distribution if compute nodes significantly
> >> >>> > differ
> >> >>> > from each other in terms of total RAM amount
> >> >>>
> >> >>> Thank you, that makes sense. I vote for enable these ones (leaving
> the
> >> >>> ram_allocation_ratio defaults) for Fuel nova manifests for Puppet.
> >> >>> That
> >> >>> do you think?
> >> >>>
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > On Thu, Mar 20, 2014 at 2:58 PM, Bogdan Dobrelya
> >> >>> > <bdobrelia@xxxxxxxxxxxx
> >> >>> > <mailto:bdobrelia@xxxxxxxxxxxx>> wrote:
> >> >>> >
> >> >>> >     On 03/20/2014 08:47 AM, Mike Scherbakov wrote:
> >> >>> >     > Hi Dmitry,
> >> >>> >     > I was running through bp created by
> >> >>> >     > you:
> >> >>> >
> >> >>> >
> >> >>> >
> https://blueprints.launchpad.net/fuel/+spec/scheduler-config-improvements.
> >> >>> >     >
> >> >>> >
> >> >>> >     Interesting, why CPU overcommitment defaults (
> >> >>> >
> >> >>> >
> >> >>> >
> https://github.com/openstack/nova/blob/master/etc/nova/nova.conf.sample#L1759
> >> >>> >     ) are so 'bad' to being changed so drastically 16->1?
> >> >>> >
> >> >>> >     > I'm wondering whether this config will work fine for every
> >> >>> >     installation
> >> >>> >     > we do with Fuel.. what are the possible limitations / corner
> >> >>> > cases?
> >> >>> >     >
> >> >>> >     > Thanks,
> >> >>> >     > --
> >> >>> >     > Mike Scherbakov
> >> >>> >     > #mihgen
> >> >>> >     >
> >> >>> >     >
> >> >>> >
> >> >>> >
> >> >>> >     --
> >> >>> >     Best regards,
> >> >>> >     Bogdan Dobrelya,
> >> >>> >     Skype #bogdando_at_yahoo.com <http://bogdando_at_yahoo.com>
> >> >>> >     Irc #bogdando
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Kind regards
> >> >>> > Dmitry Ukov
> >> >>> > IT Engineer
> >> >>> > Mirantis, Inc.
> >> >>> >
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Best regards,
> >> >>> Bogdan Dobrelya,
> >> >>> Skype #bogdando_at_yahoo.com
> >> >>> Irc #bogdando
> >> >>>
> >> >>> --
> >> >>> Mailing list: https://launchpad.net/~fuel-dev
> >> >>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >> >>> Unsubscribe : https://launchpad.net/~fuel-dev
> >> >>> More help   : https://help.launchpad.net/ListHelp
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Roman Sokolkov,
> >> >> Deployment Engineer,
> >> >> Mirantis, Inc.
> >> >> Skype rsokolkov,
> >> >> rsokolkov@xxxxxxxxxxxx
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Roman Sokolkov,
> >> > Deployment Engineer,
> >> > Mirantis, Inc.
> >> > Skype rsokolkov,
> >> > rsokolkov@xxxxxxxxxxxx
> >> >
> >> > --
> >> > Mailing list: https://launchpad.net/~fuel-dev
> >> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >> > Unsubscribe : https://launchpad.net/~fuel-dev
> >> > More help   : https://help.launchpad.net/ListHelp
> >> >
> >
> >
> >
> >
> > --
> > Roman Sokolkov,
> > Deployment Engineer,
> > Mirantis, Inc.
> > Skype rsokolkov,
> > rsokolkov@xxxxxxxxxxxx
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin@xxxxxxxxxxxx