Hi Alexey, 2017-11-07 13:46 GMT+08:00 Alexey Kardashevskiy <a...@ozlabs.ru>: > On 07/11/17 01:08, Paolo Bonzini wrote: >> On 06/11/2017 13:18, Wanpeng Li wrote: >>> 2017-11-06 20:02 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>: >>>> On 06/11/2017 12:59, Fam Zheng wrote: >>>>>>> Could you point out the patchset for the fix? >>>>>> Between 447b0d0b9ee8a0ac216c3186e0f3c427a1001f0c and >>>>>> 092aa2fc65b7a35121616aad8f39d47b8f921618. >>>>> Not sure how these relate to the core size, but I've tested upstream >>>>> (ec7a8bf0b8f7dc7288fe8745464ee8217528cc6c) and with dump-guest-core=off >>>>> the core >>>>> file is 363M, still significantly larger than rss (~73M). >>>>> >>>>> What is bloating the core file? >>>> >>>> My guess would have been fragmented heap. The core file, unlike the >>>> RSS, includes all the mmaped memory (e.g. from shared libraries) that >>>> has never been used. >>>> >>>> For example, all the Ceph/Gluster/PulseAudio/SPICE/whatever libraries >>>> are included in the core file but likely are not in the RSS. >>> >>> Do you mean not use Memory API will avoid the fragmented heap? >> >> The high memory usage from the memory API causes excessive >> fragmentation. Alexey's work should help reducing memory usage and thus >> the fragmentation. > > Since centos6 does not have this issue and centos7 does, I'd suggest > MALLOC_ARENA_MAX&co > https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.html
Thanks for the inputs. What's the recommend glibc.malloc.arena_max value from you? :) > > glibc changed some defaults between rhel/centos 6 and 7 if I recall > correctly, and these arenas now create big anon mappings per thread, these > are not really touched (so they do not use resident memory) but may appear > in these dumps, dunno. > > btw do you configure the machine to make "kill -11" produce qemu core dumps? Yeah, some tuning in /etc/libvirt/qemu.conf, max_core="unlimited", dump_guest_core=0 Regards, Wanpeng Li