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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
