[nova][scheduler] - Stack VMs based on RAM
mriedemos at gmail.com
Wed Apr 17 19:45:00 UTC 2019
On 4/17/2019 2:19 PM, melanie witt wrote:
> The relevant scheduler log is this one:
> 2019-04-17 19:53:07.303 98874 DEBUG nova.scheduler.filter_scheduler
> 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
> default default] Weighed [(cpu1, cpu1) ram: 32153MB disk: 1906688MB
> io_ops: 0 instances: 0, (cpu2, cpu2) ram: 30105MB disk: 1886208MB
> io_ops: 0 instances: 1] _get_sorted_hosts
> and here we see that host 'cpu1' is being weighed ahead of host 'cpu2',
> which is the problem. I don't understand this considering the docs say
> that setting the ram_weight_multiplier to a negative value should result
> in the host with the lesser RAM being weighed higher/first. According to
> your log, the opposite is happening -- 'cpu1' with 32153MB RAM is being
> weighed higher than 'cpu2' with 30105MB RAM.
> Either your ram_weight_multiplier setting is not being picked up or
> there's a bug causing weight to be applied with reverse logic?
> Can you look at the scheduler debug log when the service first started
> up and verify what value of ram_weight_multiplier the service is using?
I agree with Melanie's assessment. Looking at the RAMWeigher code in
Rocky we see it's weighing based on the free_ram_mb value in the
Looking at the filtered hosts that were logged:
Filtered [(cpu2, cpu2) ram: 30105MB disk: 1886208MB io_ops: 0 instances:
1, (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0]
The ram value that is logged is free_ram_mb:
It looks like you also don't have this logging regression fix in your
rocky scheduler code, so you might want to patch this in when getting
new debug logs:
That could tell us what the resulting weight is.
More information about the openstack-discuss