Reducing the number of threads that Go uses seems to help a bit:
$ cat /etc/systemd/system/lxd.service.d/override.conf
[Service]
Environment=GOMAXPROCS=1
(GOMAXPROCS defaults to the number of CPUs). But Stéphane is still able
to lock up LXD pretty fast even with that.
--
You received this bug
Very much looks like it's related to threading and futexes somehow.
Forcing golang to use a single thread rather than one per container made
things more stable using a very simple test (infinite loop of "lxc
list"), though starting containers then still caused the hang to happen.
I've seen a
I managed to get the 4x CPU instance into the same locked up state now,
so AFAICS the problem isn't fundamentally different between 4 and 8
cores.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Retitling. The "unusably slow" part was fixed with installing haveged,
so what remains is that the 8x CPU instance gets into this lockup state
after some time.
On the 4x instance I'm now running adt-run in a loop, so far it's
through ~ 10 iterations. I'll let it run over night and see how it is
4 matches
Mail list logo
