Howdy, Stranger!

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


CPU Abuse - instant suspension or just turn off the VPS?
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.

CPU Abuse - instant suspension or just turn off the VPS?

d60ebad60eba Member
edited June 2015 in General

Hi all,

Accidental CPU abuse can happen to anyone. Maybe it's a corrupted MySQL table, maybe it's a dodgy bit of code. That's part of the reason why it's important for VPS providers to monitor things and take automatic action against "abusers".

However, for a first offence, should the provider insta-suspend the user then wait for contact via a support ticket to turn it back on or should they insta-shutdown the VPS and wait for contact via a support ticket whilst still allowing the user to start it up again?

I've hosted with providers who do both. Personally, I vastly prefer the latter (shutdown, not suspend) as I don't have to wait for their support to turn it back on again. If their support is slow (or asleep in another timezone), that can mean many hours of downtime.

Interested to know your opinions.

Suspension or shutdown
  1. Should providers automatically suspend or just shutdown for a first offence?47 votes
    1. Suspend
      36.17%
    2. Shutdown
      63.83%

Comments

  • If the user is allowed to restart it, then most likely CPU abuse will occur again and if support is asleep, then that might affect other customers.

  • d60ebad60eba Member

    @PremiumN said:
    If the user is allowed to restart it, then most likely CPU abuse will occur again and if support is asleep, then that might affect other customers.

    I don't know if the monitoring scripts have the ability to do this but a suspend on a second offence would seem to be a solution to that

  • J1021J1021 Member

    Neither. I'd rather the host limited my access to CPU resources, be it lowering the amount of cores I can access or lowering the Mhz I can access.

  • If it is the first time, the user can be forgiven, I think

  • HBAndreiHBAndrei Member, Top Host, Host Rep

    This may come as a shock to you but there are some people that knowingly abuse resources, and will immediately turn the VPS back on and resume the abuse... which is why a Suspension is more efficient to get a hold of the client and see his intentions.

  • jarjar Patron Provider, Top Host, Veteran

    @kcaj said:
    Neither. I'd rather the host limited my access to CPU resources, be it lowering the amount of cores I can access or lowering the Mhz I can access.

    This. I'm in favor of limiting the CPU and starting a conversation via ticket.

  • Rob92Rob92 Member

    @Jar said:
    This. I'm in favor of limiting the CPU and starting a conversation via ticket.

    I prefer this method myself too

  • d60ebad60eba Member

    @kcaj said:
    Neither. I'd rather the host limited my access to CPU resources, be it lowering the amount of cores I can access or lowering the Mhz I can access.

    I was under the impression than on openVZ a user hammering the CPU will affect everyone's resources no matter what limits they have on them. Not true?

  • AnthonySmithAnthonySmith Member, Patron Provider
    edited June 2015

    1st time is shutdown, 2nd time is suspend to arrange a time to go over what is causing the issue with the end user.

    However there is an exception to this rule, if your CPU abuse is so excessive it is literally bringing the entire node to a halt then it needs to be suspend to reduce risk, that judgement also is based on how long you have been a customer <7 days insta suspend for example.

  • jarjar Patron Provider, Top Host, Veteran

    @d60eba said:
    I was under the impression than on openVZ a user hammering the CPU will affect everyone's resources no matter what limits they have on them. Not true?

    They can apply cpulimit to the process, that's what I used to do at Catalyst. This forcefully reduces the CPU usage.

  • AnthonySmithAnthonySmith Member, Patron Provider

    oh right, if its OpenVZ then they could have simply killed the process..

  • armindsarminds Member, Host Rep

    I believe lowering the CPU power and time for that user and/or suspension are the logical ways to stop resource abuse. Not only to shutdown.

  • I would actually use nodewatch on my openvz nodes to prevent someone from abusing the cpu and nodewatch would automatically suspend them until if I was asleep in another timezone to wake up get the report from nodewatch and then open a ticket with the customer and figure out what caused it(as having nodewatch automatically suspend the openvz container saves the other people on the node from being affected.)

  • Usually, a reboot/shutdown of the container suffices. Send the customer a email with the context of warning them, and should it occur again, they will be suspended and if they don't fix the issue, terminate.

  • FlamesRunnerFlamesRunner Member
    edited June 2015

    @PremiumN said:
    If the user is allowed to restart it, then most likely CPU abuse will occur again and if support is asleep, then that might affect other customers.

    If the user is for example having excessive traffic to multiple websites, and you suspend them on the first warning, I don't think they'll be coming back to you and renewing for the loss of traffic.

  • Jar said: This. I'm in favor of limiting the CPU and starting a conversation via ticket.

    Dedicated resources avoid all this unpleasantness. Then the customer can max out those resources without worrying about being shutdown.

  • edited June 2015

    If they have a dedicated assignment then just leave them. If its shared scale down their cpu. I usually increase the amount of cores and reduce the percentage (not GVH 24 core at 50MHz) usually around 3 cores at 800MHz or 1GHz

  • d60ebad60eba Member
    edited June 2015

    @Jar said:
    They can apply cpulimit to the process, that's what I used to do at Catalyst. This forcefully reduces the CPU usage.

    Interesting. In my recent case it was MySQL that got out of hand. A cpulimit applied to that process would have sorted it, true. I've used cpulimit daemon in past for that purpose. May be worth setting that up for mysql on my problem server just in case. ** Edit ** just tried cpulimit on mysql and it causes problems, wouldn't recommend it ...

  • d60ebad60eba Member

    @MarkTurner said:
    Dedicated resources avoid all this unpleasantness.

    Which VPS types provide dedicated resources? Would that be on KVM?

  • We manually intervene for these sorts of things, the first time or so we just kill the process, after that we will reboot the container, and only if its a continued problem do we suspend, but when the service is suspended an e-mail is automatically sent to the client asking them to contact our support desk anyway. So far its working as a good system.

  • jarjar Patron Provider, Top Host, Veteran

    @d60eba said:
    Interesting. In my recent case it was MySQL that got out of hand. A cpulimit applied to that process would have sorted it, true. I've used cpulimit daemon in past for that purpose. May be worth setting that up for mysql on my problem server just in case. ** Edit ** just tried cpulimit on mysql and it causes problems, wouldn't recommend it ...

    Doesn't work well in the container if I recall, but works well outside it.

  • d60eba said: Which VPS types provide dedicated resources? Would that be on KVM?

    For example the one in my sig is a KVM server with dedicated core, disk and RAM. The problem comes into play when a VPS provider over-oversells or overprovides (offers too much resources, that the user subsequently uses).

    If a customer has dedicated resources then you are not worried if the customer then decides to max out those allocated resources because you are not expecting them to be available to anyone else anyway.

Sign In or Register to comment.