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?
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.
- Should providers automatically suspend or just shutdown for a first offence?47 votes
- Suspend36.17%
- Shutdown63.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.
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
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
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.
This. I'm in favor of limiting the CPU and starting a conversation via ticket.
I prefer this method myself too
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?
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.
They can apply cpulimit to the process, that's what I used to do at Catalyst. This forcefully reduces the CPU usage.
oh right, if its OpenVZ then they could have simply killed the process..
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.
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.
Dedicated resources avoid all this unpleasantness. Then the customer can max out those resources without worrying about being shutdown.
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
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 ...
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.
Doesn't work well in the container if I recall, but works well outside it.
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.