fuel-dev team mailing list archive

[Andrey Korolev <akorolev@xxxxxxxxxxxx>]

On Wed, Jun 25, 2014 at 11:52 AM, Jesse Pretorius
<jesse.pretorius@xxxxxxxxx> wrote:
> On 24 June 2014 22:26, Andrey Korolev <akorolev@xxxxxxxxxxxx> wrote:
>>
>> I am wondered why everyone repeatedly suggesting memory overcommit
>> ratio to be equal one, not setting to dynamical characteristic which
>> 1. strictly lower than one,
>> 2. dependent on many parameters, including absolute memory size and
>> existence of co-resident services.
>>
>> I had said this before two times, as I can remember :)
>
>
> Well, as a counterpoint, we have tested overcommits in production of the
> following without any issues:
>
> 1) CPU 1:16
> 2) RAM 1:1.8
>
> It really all depends on how the instances are utilising resources. It only
> becomes dangerous to have high overcommit rates when you have busy instances
> utilising resources heavily.
>

I am not sure if memory footprint depends on a total workload
directly, memory for guest just tends to increase its footprint over
time (as software inside VM allocates it for first time) to reach
config-set value somewhen. Then, if you have small or no swap (common
thing nowadays), overcommit memory ratio should produce total limit
strictly lower than memory available in host to prevent performance
degradation, or, even worse, summoning OOM reaper. If you want to test
your allocation ratio proposal to meet long-term real uptime - spawn
enough count of Windows VM, they will allocate all available bytes at
very beginning.

> --
> 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
>