* 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]>
