Bug 840962 - virsh slow
virsh slow
Status: CLOSED DEFERRED
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-17 13:35 EDT by Bogdan Ćulibrk
Modified: 2016-03-23 18:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-23 18:22:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bogdan Ćulibrk 2012-07-17 13:35:04 EDT
Description of problem:

On Debian Squeeze (6.0), this seems to be some kind of bug with xenstored.

For example, let's take our servers "vm7" and "vm10" into
consideration, which are configured exactly the same, Debian Squeeze
vanilla, no backports.

"vm7", as stated below, has more Domain-0 entries, but executes virsh
commands (f.e. virsh pwd, virsh list etc) faster (under a second) than
"vm10".

[vm7 ~]# ./dump-xenstore.sh | grep Domain-0 | wc -l
22

[vm10 ~]# ./dump-xenstore.sh | grep Domain-0 | wc -l
14

If you strace xenstored by attaching to it's process, you'll see that
even the basic virsh command, like virsh pwd, doesn't finish until it
"is done" with xenstored. When xenstored finishes passing data to
virsh, virsh gives it's output.

From the strace output, xenstored on vm10 gives ~20x more ENOENT
errors than xenstored strace on vm7:

[vm7 ~]# grep ENOENT xenstored.strace | wc -l
110

[vm10 ~]# grep ENOENT xenstored.strace | wc -l
2232

From what I can deduce, there is something "wrong" with vm10's
xenstored's tdb, because it points to unexisting data and takes a lot
of time on that?

[vm10 ~]# grep tdb.0x17a47b0 xenstored.strace
2013  open("/var/lib/xenstored/tdb.0x17a47b0",
O_WRONLY|O_CREAT|O_TRUNC, 0640) = 154
2013  open("/var/lib/xenstored/tdb.0x17a47b0", O_RDWR) = 155
2013  rename("/var/lib/xenstored/tdb.0x17a47b0", "/var/lib/xenstored/tdb") = 0
2013  unlink("/var/lib/xenstored/tdb.0x17a47b0") = -1 ENOENT (No such
file or directory)
2013  open("/var/lib/xenstored/tdb.0x17a47b0",
O_WRONLY|O_CREAT|O_TRUNC, 0640) = 153
2013  open("/var/lib/xenstored/tdb.0x17a47b0", O_RDWR) = 156
2013  rename("/var/lib/xenstored/tdb.0x17a47b0", "/var/lib/xenstored/tdb") = 0
2013  unlink("/var/lib/xenstored/tdb.0x17a47b0") = -1 ENOENT (No such
file or directory)
---snip---

(last 4 lines repeated 80 times)

NB: same slowdown appears on more dom0s.



Version-Release number of selected component (if applicable):

0.8.3-5+squeeze2


How reproducible:

virsh list

or any other virsh sub-command thath involves interaction with managing domains.

eg. "virsh help" works just fine.

Steps to Reproduce:
1. virsh define 
2. virsh list 
3. virsh console 
  
Actual results:

all commands lag > 10 secs.


Expected results:

under 1-2 secs response


Additional info:
Comment 1 Cole Robinson 2016-03-23 18:22:50 EDT
I'm sorry this never received a response, but given the age of this bug and usage of the now-deprecated xend toolstack, I'm closing this as DEFERRED. If anyone can still reproduce with modern libvirt, please reopen

Note You need to log in before you can comment on or make changes to this bug.