kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Wawro <wawro@digitalmedics.de>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, "libvir-list@redhat.com" <libvir-list@redhat.com>
Subject: Re: [User question] Huge buffer size on KVM host
Date: Mon, 10 Sep 2012 11:22:39 +0200	[thread overview]
Message-ID: <504DB15F.9040509@digitalmedics.de> (raw)
In-Reply-To: <502D0A63.1070608@redhat.com>

On 08/16/2012 04:57 PM, Avi Kivity wrote:

Hi Avi,

No, there was no reason and we disabled it there too. Interestingly, the
buffer
size did not go down significantly, even when manually flushing the pages
using /proc/sys/vm/drop_caches (3), the buffer size did not go down.
Finally,
after rebooting the host, buffer size was back to normal again and when all
caches were disabled, we were also able to manually drop the buffered pages.

However, after 2 weeks or so, we encountered significant instabilities
in the system.
Inside the guest OS, the load went up like crazy (way past 30) and the 
guest
was virtually unusable. Checking the host: buffer size, load, memory,
I/O was all in
a well defined range.

When rebooting the guest OS, the problem manifested again after
about 20-30mins (reproducible a couple of times). The only thing that
worked to
stop this (I am afraid only for a couple of weeks or so), was rebooting
the host system.
On the guest and the host there was nothing suspicious in the logs or
dmesg output.


Best regards,

Martin

> Hi Avi,
>
> It seems that the kernel on that particular machine is too old, those entries are
> not featured. We checked on a comparable setup with a newer kernel and both entries
> were set to 512.
>
> We also did have a third more thorough look on the caching. It turns out that the
> virt-manager does not seem to honor the caching adjusted in the GUI correctly.
> We disabled caching on all virtual devices for this particular VM and checking
> with "ps -fxal" revealed, that only one of those devices (and a rather small one too)
> had this set. We corrected this in the XML file directly and the buffer size
> currently resides at around 1.8 GB after rebooting the VM (the only virtio device
> not having the cache=none option set is now the (non-mounted) cdrom).
>
> cc += libvirt-list
>
> Is there a reason that cdroms don't get cache=none?
>
>


-- 
--------------------------------------------------------------------
Martin Wawro           |                         Digital Medics GmbH 
Managing Director      |  Otto-Hahn-Str. 15, 44227 Dortmund, Germany
Tel. +49-231-9742-6622 |                      Fax: +49-231-9742-6623
Key: 0xB0A225BD        |        Registered at AG Dortmund, HRB 19360
--------------------------------------------------------------------


      reply	other threads:[~2012-09-10  9:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-15  8:06 [User question] Huge buffer size on KVM host Martin Wawro
2012-08-15 11:30 ` Avi Kivity
2012-08-15 12:05   ` Martin Wawro
2012-08-15 12:57     ` Avi Kivity
2012-08-16 14:54       ` Martin Wawro
2012-08-16 14:57         ` Avi Kivity
2012-09-10  9:22           ` Martin Wawro [this message]

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=504DB15F.9040509@digitalmedics.de \
    --to=wawro@digitalmedics.de \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=libvir-list@redhat.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).