Hi Stefan, Thanks a lot, that solved the problem! However, I still wonder why the difference in cputime consumption between a FreeBSD KVM and a OpenBSD KVM (both just a basic install) is so huge ... now I see 643min on OpenBSD vs 46min on FreeBSD.
Regards, Robert > Gesendet: Freitag, 12. Januar 2018 um 12:48 Uhr > Von: "Stefan Fritsch" <[email protected]> > An: Infoomatic <[email protected]> > Cc: [email protected] > Betreff: Re: Performance issues as KVM guest? > > Hi, I don't see this issue on my Debian system, but please try two things: * > disable kvm_intel.preemption_timer on the host (see > /sys/module/kvm_intel/parameters/preemption_timer ) This seems to be buggy in > linux 4.10 and newer * enable hpet in the vm config: Make sure there is no in > your libvirt xml (or don't pass -ho-hpet to qemu). Unfortunately, newer > libvirt versions seem to disable hpet by default. Different issue: If you > remove the USB controllers, the CPU load on the host will reduce by a few > percent (~ 3%). Add and remove all other usb controller sections. Just > removing the usb controller sections without adding the 'none' makes libvirt > add them back (this is stupid). Cheers, Stefan On Fri, 12 Jan 2018, > Infoomatic wrote: > Same problem here. While we did have significant > differences in cpu > usage between FreeBSD and OpenBSD (basic OS without > configuration: > FreeBSD ~ 33min CPU time, OpenBSD ~ 474min CPU time - both > started at > the same time), with the latest kernel patches for Ubuntu 17.04 > (our > test environments all run Ubuntu 17.04 for KVM VMs), OpenBSD now > becomes > practically unusable: as soon as I su or login on the console with > su, > cpu usage is at 100% - the system freezes. :-/ guess we need some > > dedicated BSD machines to host some test-VMs ;-) > > Regards, > Robert > > > > > Gesendet: Donnerstag, 11. Januar 2018 um 20:32 Uhr > > Von: "Kirill > Miazine" > > An: [email protected] > > Betreff: Re: Performance issues as KVM > guest? > > > > * Kent Watsen [2018-01-11 17:38]: > > [...] > > > > > Since my > hosting provider https://www.bytemark.co.uk/cloud-hosting/ > > > > > patched > for Meltdown last weekend I'm seeing significant performance > > > > > issues > with an OpenBSD virtual instance there. It seems okay after a > > > > > fresh > reboot but then progressively returns to being very slow: for > > > > > > example "sleep 1" may take four seconds, then five, six, seven, then > > > > > > rather more. Curiously it does tend to be an integral multiplier. > > > > > > > > > > > I wondered, is anybody else seeing significant performance problems > with > > > > > OpenBSD (or other BSDs) virtual instances since Meltdown > patching? Is > > > > > there anything to tweak at my end or am I reliant on > the provider? > > > > > > > > > > -- Mark > > > > > > > > > There are a ton > of threads talking about this issue, and it's not meltdown > > > > specific. > Please search the archives. > > > > > > > > -ml > > > > > > [...] > > > Also, > Mark, could you say some more about the issue. For instance, how long > > > > after a reboot does it take until you start to notice the issue, and how > > > > quickly does it get worse? > > > > I'm another customer of Bytemark > experiencing the same issue. I'm taking > > care of one VM there and I'm > primarly noticing it in two situations: > > sleep() takes a long time (e.g. > sleep(1) might take up to 40 seconds) > > and the clock slows down. > > > > > Right now, 9 hours after reboot, the clock on VM is 3 hours behind real > > > clock. And sleep(1) takes 13 secs: > > > > km@buildfarm ~ $ time sleep 1 > > > 0m13.85s real 0m00.00s user 0m00.01s system > > > > This all started after > the host was patched and VM rebooted. > > > > Bytemark guys are looking at > the issue and doing their own debugging. > > Here're findings so far: > > > > > I spun a few OpenBSD VMs up and left them overnight - looks like the > > > clock isn't drifting but there's still the 'time sleep 1' issue. > > My > testing results seemed to concur with User_4574's, virtio was slowing > > > down only a few minutes after a fresh install whereas compatibility > > would > stick at 1s, jump to 2s, etc. > > > > > > Thanks, > > > Kent > > > > > > > -- > > > -- Kirill Miazine > > > > > >
