fuel-dev team mailing list archive

[Andrey Korolev <akorolev@xxxxxxxxxxxx>]

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