Open Stack

On 09/27/2017 03:10 PM, Premysl Kouril wrote:
>> Lastly, qemu has overhead that varies depending on what you're doing in the
>> guest.  In particular, there are various IO queues that can consume
>> significant amounts of memory.  The company that I work for put in a good
>> bit of effort engineering things so that they work more reliably, and part
>> of that was determining how much memory to reserve for the host.
>>
>> Chris
>
> Hi, I work with Jakub (the op of this thread) and here is my two
> cents: I think what is critical to realize is that KVM virtual
> machines can have substantial memory overhead of up to 25% of memory,
> allocated to KVM virtual machine itself. This overhead memory is not
> considered in nova code when calculating if the instance being
> provisioned actually fits into host's available resources (only the
> memory, configured in instance's flavor is considered). And this is
> especially being a problem when CPU pinning is used as the memory
> allocation is bounded by limits of specific NUMA node (due to the
> strict memory allocation mode). This renders the global reservation
> parameter reserved_host_memory_mb useless as it doesn't take NUMA into
> account.
>
> This KVM virtual machine overhead is what is causing the OOMs in our
> infrastructure and that's what we need to fix.

Feel free to report a bug against nova...maybe reserved_host_memory_mb should be 
a list of per-numa-node values.

It's a bit of a hack, but if you use hugepages for all the guests you can 
control the amount of per-numa-node memory reserved for host overhead.

Since the kvm overhead memory is allocated from 4K pages (in my experience) you 
can just choose to leave some memory on each host NUMA node as 4K pages instead 
of allocating them as hugepages.

Chris