[Pkg-xen-devel] Bug#666135: Multiple "Domain-0", slow libvirt
Bogdan Ćulibrk
bc at default.rs
Mon Jul 9 13:06:04 UTC 2012
In our case, 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.
More information about the Pkg-xen-devel
mailing list