public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Hermann Himmelbauer <dusty@qwer.tk>
To: kvm@vger.kernel.org
Subject: Gests periodically stuck for ~ 10-15 seconds - what to do?
Date: Sat, 23 Oct 2010 22:37:41 +0200	[thread overview]
Message-ID: <201010232237.42005.dusty@qwer.tk> (raw)

Hi,
I'm quite new to virtualization and KVM, I have a 2*4-core Intel machine here 
with 16GB RAM and Debian Lenny as host. I further installed two Debian Lenny 
guests, one with 2 CPUs, the other with one. The guests were installed 
similar to this:

virt-install --connect qemu:///system -n MyVMName -r 1024 --vcpus=2 -f 
path/to/qcow2_file -s 12 -c ~/debian-503-amd64-netinst.iso --vnc -k 
de --noautoconsole --os-type linux --os-variant 
debianLenny --accelerate --network=bridge:br0 --hvm

The guests have the virtio_blk and virtio_net devices installed to improve 
disk/networking performance.

After a while I experienced strange guest lockups, whereas I got the 
famous "CPU #0 stuck for ...seconds". I then upgraded both the host and the 
guest kernel from 2.6.26 (Lenny default) to 2.6.32-bpo.5-amd64, moreover I 
upgraded kvm to qemu-kvm-0.12.5

The "CPU stuck" messages are gone now, but I still experience stucks in the 
guest. They come from time to time, sometimes not for an hour, sometimes 
every 5 seconds. These "stucks" last something between 3 seconds to 30 
seconds.

I am not 100% sure but it seems that these stucks come from the disk I/O. I 
wrote two little scripts, one that outputs the continuity of disk reads, the 
other the continuity of CPU calculations. It's interesting to see that the 
calculations continue while the disk-read script is stuck, which leads me to 
the conclusion that the problem is disk-I/O bound.

It's moreover interesting to see that these stucks happen synchronously at 
both guest systems, while the host seems not to be affected.

Moreover, it's interesting that the read speed is sometimes stable at ~ 
80MB/s, while it is at other times only at ~ 40 MB/s.

During these tests the system is fully idle (apart from the tests, of course). 
The program "iotop" shows the I/O fully idle during these stucks.

Rebooting the guests seem to make the problem go away - but only for some 
time.

The whole issue is quite bad as the guests are virtually unusable with these 
stucks, working is horrific, a simple "ls" takes sometimes up to 30 seconds 
although the whole system (host + other guests) are fully idle and I have no  
clue how to fix this.

Any ideas?

Best Regards,
Hermann

-- 
hermann@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7

             reply	other threads:[~2010-10-23 20:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-23 20:37 Hermann Himmelbauer [this message]
2010-10-23 21:40 ` Gests periodically stuck for ~ 10-15 seconds - what to do? Hermann Himmelbauer

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=201010232237.42005.dusty@qwer.tk \
    --to=dusty@qwer.tk \
    --cc=kvm@vger.kernel.org \
    /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