Re: Libvirt slow after a couple of months uptime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 16, 2022 at 19:41:28 +0200, André Malm wrote:
> Hello,
> 
> I have some issues with libvirtd getting slow over time.
> 
> After a fresh reboot (or systemctl restart libvirtd) virsh list /
> virt-install is fast, as expected, but after a couple of months uptime they
> both take a significantly longer time.
> 
> Virsh list takes around 3 seconds (from 0.04s on a fresh reboot) and
> virt-install takes over a minute (from around a second).
> 
> Running strace on virsh list it seems to get stuck in a loop on this:
> poll([{fd=5<socket:[173169773]>, events=POLLOUT},
> {fd=6<anon_inode:[eventfd]>, events=POLLIN}], 2, -1) = 2 ([{fd=5,
> revents=POLLOUT}, {fd=6, revents=POLLIN}])

Unfortunately this bit doesn't help much. Virsh' is simply a client
which does RPC over a unix socket to the libvirt/virtqemud daemon based
on your host configuration.

This means that what you straced was simply a event loop waiting for the
communication with the server. In fact there's a whole thread simply for
polling and dispatching the calls so it's expected that it's always
stuck in a poll().

> While restarting libvirtd fixes it

So it looks like the problem isn't in virsh at all. In such case
stracing virsh won't help at all as it's a completely different process
from the dameon.

> a restart takes around 1 minute where
> ebtables rules etc are recreated and it does interrupt the service. What
> could cause this? How would I troubleshoot this?

The best way to at least get an idea where the problem might be would be
to collect debug logs of the libvirt daemon (libvirtd/virtqemud based on
how your host is configured).

To enable debug logs you can use the following guide, which also
explains how to figure out which daemon is in use and also outlines how
to set it without restarting the daemon. Make sure to read the
appropriate chapters:

https://www.libvirt.org/kbase/debuglogs.html

The log contains timestamps so we'll be able to see what bogs down the
runtime once it's in the 'slow' period.





[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux