Just spent a while pulling my hair out with this. A new installation on a Hetzner VM, but the issue seems likely to be reproducible whenever your install is using virtio_random.ko. A bog standard MySQL would hang for at least an hour on first start.
The issue is that rand_harvestq would peg a CPU core and take approximately forever to return. Something in mysql initialization depends on random numbers enough that this would peg another core with mysqld at 100% but stuck in uwait status. My 2-core VM became very unresponsive at this point, though a larger one may remain usable (unsure if mysql would peg many cores waiting), with a core dedicated each to harvesting entropy stupidly slowly and waiting on that entropy.
Solution: blacklist virtio_random.ko and restart. It seems that
Add this to /etc/rc.conf
Further reading:
- https://forums.freebsd.org/threads/freebsd-13-high-cpu-usage-rand_harvestq.80475/
- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230808
- https://bugs.freebsd.org/bugzilla//show_bug.cgi?id=254513
The issue is that rand_harvestq would peg a CPU core and take approximately forever to return. Something in mysql initialization depends on random numbers enough that this would peg another core with mysqld at 100% but stuck in uwait status. My 2-core VM became very unresponsive at this point, though a larger one may remain usable (unsure if mysql would peg many cores waiting), with a core dedicated each to harvesting entropy stupidly slowly and waiting on that entropy.
Solution: blacklist virtio_random.ko and restart. It seems that
kldunload virtio_random will hang, so the restart is necessary.Add this to /etc/rc.conf
Code:
devmatch_blacklist="virtio_random.ko"Further reading:
- https://forums.freebsd.org/threads/freebsd-13-high-cpu-usage-rand_harvestq.80475/
- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230808
- https://bugs.freebsd.org/bugzilla//show_bug.cgi?id=254513