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" <[email protected]> > 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 <[email protected]> > >
