LXD or snap slowness

LXD
1

Hey folks,

I’ve seen this a few times on different machines, lxc commands get super-slow (for example lxc version taking many minutes to complete, and it’s not the lxd server that’s slow). For giggles, here’s time lxc help:

real	1m37.312s
user	0m0.333s
sys	0m17.979s

In iotop, I see the loop3 process doing a lot of reading:

   891 be/0 root     /                   6.63 M/s    0.00 B/s  0.00 % 49.05 % [loop3]

This is constant, though sometimes it’s much higher than that. /dev/loop3 belongs to the current snap build, but it’s interesting to note there’s an older version still mounted:

# df -h | grep lxd
/dev/loop0       55M   55M     0 100% /snap/lxd/11727
/dev/loop3       55M   55M     0 100% /snap/lxd/12211

Any ideas how to break this loose? Ideally without restarting all the containers would be good. The last time it happened I simply rebooted the machine because it needed to work now, but snap is fast making things that require a reboot a habit. :confused:

2

Maybe download the source, compile the client, try to reproduce with the not snapped client; if the same problem happens, you could strace -r lxc client, possibly with threads enabled (-f -ff -o myfile) and it should show you what is slow. If the problem does NOT happen with a compiled client, you will know that snap is the culprit.

3

Thanks, I don’t know if that approach will work though because I can’t even reproduce it with the snap client. If I restart the affected machine, it’s fine. It’s interesting that the old versions of the snaps are still mounted, but if I refresh back and forth a bunch of times to get a test machine stuck with both versions mounted, it’s still responsive and not hammering the loop devices like that. :frowning: