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.
Comments
Strict resource limits doesn't necessarily mean you won't be suspended, as you may still overload the server in some way (as you mentioned, especially for OpenVZ.) I suppose if you're worried about a provider allowing you to burst but then enforcing their fair usage policy strictly, that is a legitimate concern. However, not all hosts that allow you to burst are like that.
For example, since deploying our automated fair use policy / anti-abuse system, about 3.2% of customers were "flagged" and about 2% warned once. Then under 1% were ever powered off after multiple at least one warning, and only 0.17% of customers have been suspended for ignoring multiple warnings & having extreme usage. Therefore, based on our data, I don't believe (at least with us) that it's a rational fear to make "a lot of people" people feel like they would prefer 1x dedicated resources over 1-2x burstable. Especially when you factor in the cost, I don't believe 97% of customers paying 2-3x more is worth it when only 3% may require strict/dedicated resources to avoid suspensions.
Only a small portion of customers feel the need to purchase our dedicated CPU addon, which equates to about 2.3% of our revenue - so again, I don't believe many people share your sentiment. I don't think it's justified to force 100% of customers to pay us ~50% of our revenue for strict/dedicated resources they don't require (compared to 2x burst.) We're actually working on also possibly adding a "high I/O" option which would eliminate suspensions on that side of the spectrum as well.
Glad it wasn't us. There were a few cases where this did occur when we tested our abuse system on a few nodes, but the false positives should all be ironed out. We actually shut down the entire automated system for a while to improve it before deploying it again, and the situation you described sounded similar so I just wanted to be sure it hasn't occur recently.