[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu core file size

From: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] qemu core file size
Date: Tue, 7 Nov 2017 16:46:31 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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 <address@hidden>:
>>> 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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]