From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Xulei (Stone)" <stone.xulei@huawei.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
"yang.zhong" <yang.zhong@intel.com>,
"anthony.xu" <anthony.xu@intel.com>,
pbonzini <pbonzini@redhat.com>, berrange <berrange@redhat.com>,
"Gonglei (Arei)" <arei.gonglei@huawei.com>,
"wangxin (U)" <wangxinxin.wang@huawei.com>,
"Huangweidong (C)" <weidong.huang@huawei.com>,
Zhanghailiang <zhang.zhanghailiang@huawei.com>,
"liujunjie (A)" <liujunjie23@huawei.com>
Subject: Re: [Qemu-devel] [Question] Qemu's Heap Becomes Very Large and Never Reduce Down
Date: Wed, 15 Nov 2017 11:00:19 +0000 [thread overview]
Message-ID: <20171115110019.GF8130@stefanha-x1.localdomain> (raw)
In-Reply-To: <8E78D212B8C25246BE4CE7EA0E645FE501B557EA@dggeml511-mbs.china.huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]
On Wed, Nov 15, 2017 at 03:14:52AM +0000, Xulei (Stone) wrote:
> Hi, guys
>
> I met a strange problem, with qemu 2.8.1:
> qemu consumes too many heap memory after several operations and can not release them anymore:
> hot pulg/unplug disk & net, vnc connect/disconnect, guestOS reboot, etc.
>
>
> 01a7a000-3b4efe000 rw-p 00000000 00:00 0 [heap]
>
> Size: 15520272 kB
>
> Rss: 14421836 kB
>
> Pss: 14421836 kB
>
> Shared_Clean: 0 kB
>
> Shared_Dirty: 0 kB
>
> Private_Clean: 1164 kB
>
> Private_Dirty: 14420672 kB
>
> Referenced: 7485624 kB
>
> Anonymous: 14421836 kB
>
> AnonHugePages: 34816 kB
>
> Swap: 1098140 kB
>
> KernelPageSize: 4 kB
>
> MMUPageSize: 4 kB
>
> Locked: 0 kB
>
> VmFlags: rd wr mr mw me ac sd
>
> My steps are:
> 1) start several VMs all equipped only 8G memory;
> 2) random combining those operations mentioned above;
> 3) after few hours, qemu's Virt memory and RSS both grow too large and never fall down;
>
> After analysis via /proc/$pid/smaps, I found the VMA of pc.ram does not occupy much
> memory but only becauses of heap section.
>
> I guess that has some relations of glibc or qemu rcu_thread, but i can not figure it out.
> Is there some patches can fix this problem or does somebody have any idea?
Please try qemu.git/master.
The malloc implementation (glibc, tcmalloc, jemalloc) probably makes a
difference since you are seeing heap growth.
The main question your report raises is that "random combining those
operations mentioned above" makes it hard to identify the operation that
leads to heap growth. Can you run isolated tests that do only
hotplug/unplug *or* VNC connect/disconnect *or* guest OS reboot, not
everything together?
Thanks,
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2017-11-15 11:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 3:14 [Qemu-devel] [Question] Qemu's Heap Becomes Very Large and Never Reduce Down Xulei (Stone)
2017-11-15 11:00 ` Stefan Hajnoczi [this message]
2017-11-15 13:18 ` Paolo Bonzini
2017-11-16 1:43 ` Zhong Yang
2017-11-16 3:08 ` Xulei (Stone)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171115110019.GF8130@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=anthony.xu@intel.com \
--cc=arei.gonglei@huawei.com \
--cc=berrange@redhat.com \
--cc=liujunjie23@huawei.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stone.xulei@huawei.com \
--cc=wangxinxin.wang@huawei.com \
--cc=weidong.huang@huawei.com \
--cc=yang.zhong@intel.com \
--cc=zhang.zhanghailiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).