New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
0.00 steal on Contabo? Unbelievable?
I have been monitoring the cpu stats on my Contabo SSD XL box, which surprisingly works much better than the Hetzner SB33 I used to have, and I notice that the cpu steal is 24/7 at 0.00 despite running two minecraft servers and a couple of telegram bots which aren't really gentle on cpu requirements.
Could it be possible that they're hiding the value, or could it be real that i have no steal at all?
While running "stress", the steal is still 0.0.
Comments
There you go - there is nothing to steal ¯_(ツ)_/¯
He's running a stress on 10 cores in the screenshot
His neighbours steal will be high I imagine
Yes you probably have a kernel which doesn't measure steal. We had this in another thread and tried to figure out which config options are responsible for that, but it lead to nothing conclusive.
I was wondering why that load number hasn't (yet) hit 10 and then I figured it's only been 42s since he's started stress...but considering his 5m and 15m avgs, there's definitely some stealing going on otherwise his 42s avg should be ~(2+6) nearer 8 than where it is. I guess this is likely what @rm_ is pointing out.
They've likely modified the kernel to not report CPU steal percentage. I've seen other providers do this too (eg. BinaryLane does it).
It's the
KVM_FEATURE_STEAL_TIME
flag, but as far as I know you need to patch the kernel code to disable it. I don't think it's an option in the configuration.On another matter, try to kill that zombie
Mostly steal is not reported somehow
but you can find if there is steal or not by simple benchmark on intervals
I would do this
1- run Stress-ng for cpu to calculate the bogo ops
2- rerun the same test every hour or so
3- if there is really no steal the runs should almost give identical bogo ops count
4- if not then calclate the diffence between the highest bogo ops and lowest to see how much steal the worst case was
the command to do so is this
stress-ng --matrix 0 -t 60s --metrics-brief
actually this looks like fun experiment
make sure to keep the test running for max 1 min per run as that will give more accurate results in case there is hidden stealing
nice signature you have
Its not the bloody french.
I don't think this is "likely", as this falls apart easily at the first kernel upgrade of the used distro. (Or if you are not using the distro kernel which upgrades regularly, then you should).
Some larger hosts have ops teams that handle kernel upgrades, and apply any patches they're using in their environment. They could be using the distro's kernel source with some patches applied on top of it, similar to what you'd do for something like OpenVZ.
It's also possible there's some other way to configure the
KVM_FEATURE_STEAL_TIME
setting (like a runtime flag) that I'm not aware of.You can run these: https://romanrm.net/dd-benchmark
dd if=/dev/zero bs=1M count=1024 | md5sum
Instead of full unixbench, if you run these 4 times a day and you notice %% difference without any steal, you are likely getting scammed.
The kernel is stock Debian Buster one. I dd all my servers with netboot.xyz and install from there
He looks cute, i have no idea what it is
We mean the kernel on the host machine, not on the VM. The host machine reports the stolen CPU percentage to the virtual machine, but there's some ways of hiding that by modifying the kernel on the host.
It should be possible to disable it without patching the host kernel by passing "-kvm_steal_time" parameter to QEMU.