Re: bhyve performance issues

On 20.12.24 07:25, Daniel Tameling wrote:
> htop is not 100% reliable. You should verify it with top.
>
> top -S show you system processes. That should tell you what makes the system unresponsive. You could also check use systat. Pure systat shows you the system load and systat -iostat shows you whether the linux build maxes out the IO capabilities of your system.
>

This was my initial suspicion, too. However, it was roughly the same as
top -S has shown, processes with with most WCPU are bhyve (~150%) and
kernel and idle jumping back and forth between 5 and 500% and here and
there zfs appearing, so nothing unusual. systat -iostat shows IO is
pretty saturated, and no weird interrupt storms or something unusual.

When the system is in this unfavorable state, a DNS lookup using drill
on the host takes > 10 seconds (the host is in a datacenter and has a
decent 1GBit connection, usually this is done in under 100ms (mostly
between 15 and 50))

I found this [1] thread and tried to replace virtio-blk with nvme. This
improved the situation - reducing load to 20-25 (dns request on the host
~ 4 seconds). Build time in the linux vm is down to  17 minutes from 23.

Further improvement can be reached by setting priority="10" in the
vm.conf file which increases niceness/lowers priority.
Build time increases by roughly 20 seconds (which I really do not care
in this setting), whereas responsiveness on the host increases quite a
bit. Using priority="16" adds just 10 seconds more and further increases
responsiveness to a level where working on the host is fine and one
barely recognizes that the system is actually doing something in a VM,
which is my desired state.

I will also have a look at the rctl settings and maybe do some scheduler
tweaking - the sysctls kern.sched come to mind.

However, imho a guest being able to cannibalize the hosts resources in
such a way that the host becomes barely usable (with the default
configuration) should be improved.

Thanks for your input!

Robert

[1]
https://lists.freebsd.org/archives/freebsd-virtualization/2024-February/001952.html