Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


0.00 steal on Contabo? Unbelievable?
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.

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

  • edfox said: despite running two minecraft servers and a couple of telegram bots which aren't really gentle on cpu requirements.

    There you go - there is nothing to steal ¯_(ツ)_/¯

  • MikeAMikeA Member, Patron Provider
    edited August 2019

    @MrPsycho said:

    edfox said: despite running two minecraft servers and a couple of telegram bots which aren't really gentle on cpu requirements.

    There you go - there is nothing to steal ¯_(ツ)_/¯

    He's running a stress on 10 cores in the screenshot :smiley:

  • jackbjackb Member, Host Rep

    @MikeA said:

    @MrPsycho said:

    edfox said: despite running two minecraft servers and a couple of telegram bots which aren't really gentle on cpu requirements.

    There you go - there is nothing to steal ¯_(ツ)_/¯

    He's running a stress on 10 cores in the screenshot :smiley:

    His neighbours steal will be high I imagine

  • rm_rm_ IPv6 Advocate, Veteran
    edited August 2019

    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.

  • MikeA said: He's running a stress on 10 cores in the screenshot

    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.

    Thanked by 2MikeA uptime
  • Daniel15Daniel15 Veteran
    edited August 2019

    They've likely modified the kernel to not report CPU steal percentage. I've seen other providers do this too (eg. BinaryLane does it).

    rm_ said: We had this in another thread and tried to figure out which config options are responsible for that, but it lead to nothing conclusive.

    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.

    Thanked by 2uptime saibal
  • angstromangstrom Moderator

    @edfox said:

    On another matter, try to kill that zombie :smiley:

    Thanked by 1AlwaysSkint
  • servarica_haniservarica_hani Member, Patron Provider

    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

    Thanked by 1vimalware
  • cociucociu Member
    edited August 2019

    edfox said: let fuck this provider with my shit comment

    nice signature you have :)

  • NeoonNeoon Community Contributor, Veteran
    edited August 2019

    Its not the bloody french.

  • rm_rm_ IPv6 Advocate, Veteran

    Daniel15 said: They've likely modified the kernel to not report CPU steal percentage.

    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).

  • rm_ said: I don't think this is "likely", as this falls apart easily at the first kernel upgrade of the used distro.

    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.

  • NeoonNeoon Community Contributor, Veteran
    edited August 2019

    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.

  • @rm_ said:
    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.

    The kernel is stock Debian Buster one. I dd all my servers with netboot.xyz and install from there

    @angstrom said:

    On another matter, try to kill that zombie :smiley:

    He looks cute, i have no idea what it is

  • edfox said: The kernel is stock Debian Buster one.

    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.

    Thanked by 1uptime
  • exception0x876exception0x876 Member, Host Rep, LIR

    It should be possible to disable it without patching the host kernel by passing "-kvm_steal_time" parameter to QEMU.

Sign In or Register to comment.