4 ms·

I work for a cloud provider (not hetzner), and sorry, but this is normal behaviour for them. Every infrastructure is based on the principle that nobody will us

I work for a cloud provider (not hetzner), and sorry, but this is normal behaviour for them. Every infrastructure is based on the principle that nobody will use all of their ability at the same time. Road network? Good luck with a whole city in their cars at the exact same time. Power distribution? Tell that to the british grid when all of britain turns on their kettles at the same time during sports events (live broadcasts are out of phase from regions to the next to alleviate this issue). Or to their sewage system, where all toilets flush at the same time once the human byproduct of said kettles is produced. So yes, this is a hosting provider where the bandwidth is shared, they overcommit it, otherwise they would not be able to do them for that cheap (in case of hetzner), or at all at a profit (for other providers that are not bottom-end). Here they tell it is unlimited, because there is no data cap. The same goes for virtual machines in a cloud environment, those too are overcommitted, and I can guarantee you that if you spawn AWS instances and use 80% flat of CPU 24/7/365 you'll get the same kind of email directing you to the cpu dedicated instances. Actually, they even did you a favor for not kicking you out due to "trust and safety" flagging you as fraud (like sending spam or ddos, which they 100% should have btw).

lazide 4y ago
For 1Gbps? That’s bullshit.
secondcoming 4y ago
Some of our GCP machines use far more than 80% CPU 24/7/365 on both preemptible and non-preemptible instances. We've yet to be asked to move to dedicated machines. It was pretty much the same when we were on AWS. I don't see how a cloud provider can complain about high CPU-usage if they bill by the machine and by the minute. Otherwise 20% of your bill is for idle CPUs.
- tuetuopay 4y ago
  It really depends how wide your impact is. When you have a lot of instances with this behaviour, you generate a lot of CPU steal for the neighbors on the same hypervisor (depending on the mitigations they put in place). If you happen to impact too many customers (many performance issue tickets), then the CSP will be more than happy to reach out to you to "upgrade" you. It really boils down to the business impact you have on them. Sure, you pay for the resource, but they are not guaranteed. And it is up to their discretion to de-prioritize your VMs on the HV, so that you're the last to get scheduled when the host's CPU is starved. This is the whole 'CPU credits' thing on AWS that they document in [0] where you can burst above the baseline. Interestingly, note that the baseline is in the 30% ballpark in their illustration on the bottom of the page :) [0]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstabl...
  - secondcoming 4y ago
    Fuck that. I'm paying for time on an agreed amount of vCPUs as specified in the instance templates. I'm using them 100%, I'd be a moron not to. It's also fraud because AWS get to charge me when I'm not scheduled, but they also charge the users who are scheduled on the contended CPU. They should bill by the CPU cycles I consume. Anyway, we've moved from AWS. Lucky escape.
  - Hikikomori 4y ago
    This only applies to T type instances, that you likely wouldn't be using for something serious.
  - gcbirzan 4y ago
    That aws things you linked is for a specific type of instances, for which they clearly state that you cannot run at 100 percent cpu all the time. It even says so in the first sentence > Traditional Amazon EC2 instance types provide fixed CPU resources, while burstable performance instances provide a baseline level of CPU utilization with the ability to burst CPU utilization above the baseline level. If the provider you are working for is doing this crap, then it sucks.
gcbirzan 4y ago
> The same goes for virtual machines in a cloud environment, those too are overcommitted, and I can guarantee you that if you spawn AWS instances and use 80% flat of CPU 24/7/365 you'll get the same kind of email directing you to the cpu dedicated instances. Yeah, that's bullshit.
shkkmo 4y ago
> Here they tell it is unlimited, because there is no data cap There literally is a data cap...and it is one which Hetzner refuses to specify. The unspecified data cap is "drastically lower" (in Hetzner's own words) than even the 80% usage which the customer was hitting. If you have to use drastically less than 100% usage, then those numbers should absolutely be published and using the term "unlimited" instead of publishing the limits is highly unethical. The "other companies do it too" argument is silly since the behavior shouldn't be normalized in the first place.
cthalupa 4y ago
>I can guarantee you that if you spawn AWS instances and use 80% flat of CPU 24/7/365 you'll get the same kind of email directing you to the cpu dedicated instances. This is a pretty significant claim that I think we're going to need evidence of. I would be flat out shocked if any of the major cloud providers gave you this sort of notice. All of them have burstable instance types with various mechanisms for limiting that burst, but I have never heard of anyone ever getting this sort of email just for heavily and consistently utilizing CPU on a regular instance. However, I will agree that this sort of thing around "unlimited bandwidth" is normal in the hosting industry. People talked all the time on webhostingtalk about all of the different dedicated server and colo providers that advertised "unlimited" bandwidth and would cut you off if you actually tried to use eit.

lazide 4y ago

For 1Gbps? That’s bullshit.

secondcoming 4y ago

Some of our GCP machines use far more than 80% CPU 24/7/365 on both preemptible and non-preemptible instances. We've yet to be asked to move to dedicated machines. It was pretty much the same when we were on AWS. I don't see how a cloud provider can complain about high CPU-usage if they bill by the machine and by the minute. Otherwise 20% of your bill is for idle CPUs.

tuetuopay 4y ago
It really depends how wide your impact is. When you have a lot of instances with this behaviour, you generate a lot of CPU steal for the neighbors on the same hypervisor (depending on the mitigations they put in place). If you happen to impact too many customers (many performance issue tickets), then the CSP will be more than happy to reach out to you to "upgrade" you. It really boils down to the business impact you have on them. Sure, you pay for the resource, but they are not guaranteed. And it is up to their discretion to de-prioritize your VMs on the HV, so that you're the last to get scheduled when the host's CPU is starved. This is the whole 'CPU credits' thing on AWS that they document in [0] where you can burst above the baseline. Interestingly, note that the baseline is in the 30% ballpark in their illustration on the bottom of the page :) [0]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstabl...
- secondcoming 4y ago
  Fuck that. I'm paying for time on an agreed amount of vCPUs as specified in the instance templates. I'm using them 100%, I'd be a moron not to. It's also fraud because AWS get to charge me when I'm not scheduled, but they also charge the users who are scheduled on the contended CPU. They should bill by the CPU cycles I consume. Anyway, we've moved from AWS. Lucky escape.
- Hikikomori 4y ago
  This only applies to T type instances, that you likely wouldn't be using for something serious.
- gcbirzan 4y ago
  That aws things you linked is for a specific type of instances, for which they clearly state that you cannot run at 100 percent cpu all the time. It even says so in the first sentence > Traditional Amazon EC2 instance types provide fixed CPU resources, while burstable performance instances provide a baseline level of CPU utilization with the ability to burst CPU utilization above the baseline level. If the provider you are working for is doing this crap, then it sucks.

gcbirzan 4y ago

> The same goes for virtual machines in a cloud environment, those too are overcommitted, and I can guarantee you that if you spawn AWS instances and use 80% flat of CPU 24/7/365 you'll get the same kind of email directing you to the cpu dedicated instances. Yeah, that's bullshit.

shkkmo 4y ago

> Here they tell it is unlimited, because there is no data cap There literally is a data cap...and it is one which Hetzner refuses to specify. The unspecified data cap is "drastically lower" (in Hetzner's own words) than even the 80% usage which the customer was hitting. If you have to use drastically less than 100% usage, then those numbers should absolutely be published and using the term "unlimited" instead of publishing the limits is highly unethical. The "other companies do it too" argument is silly since the behavior shouldn't be normalized in the first place.

cthalupa 4y ago

>I can guarantee you that if you spawn AWS instances and use 80% flat of CPU 24/7/365 you'll get the same kind of email directing you to the cpu dedicated instances. This is a pretty significant claim that I think we're going to need evidence of. I would be flat out shocked if any of the major cloud providers gave you this sort of notice. All of them have burstable instance types with various mechanisms for limiting that burst, but I have never heard of anyone ever getting this sort of email just for heavily and consistently utilizing CPU on a regular instance. However, I will agree that this sort of thing around "unlimited bandwidth" is normal in the hosting industry. People talked all the time on webhostingtalk about all of the different dedicated server and colo providers that advertised "unlimited" bandwidth and would cut you off if you actually tried to use eit.