- 最新
- 最多得票
- 最多評論
Hello.
You are right to be concerned about how CPU bursting works on certain instance types especially if you are seeing performance issues.
Monitor CPU Credits
- Keep an eye on your CPU credit balance using CloudWatch. If you see that your credits are consistently running low, consider a different instance type or strategy.
Move to a Larger Instance
- If you need more consistent CPU performance, consider upgrading to an instance type with a higher baseline or one that doesn't rely on bursting EX. Lightsail instances with more CPUs or EC2 instances like the M5 series.
Spread Workload
- If possible spread-out CPU-intensive tasks to avoid spikes. This could involve scheduling backups during off-peak hours or optimizing the workload to reduce CPU usage.
Use Reserved Instances
-
If you require constant predictable performance, switching to an instance type with a reserved instance might make sense, where you get dedicated CPU resources without relying on burst credits.
-
If your instance runs out of CPU burst credits it will be throttled to a lower performance level which can make it feel unresponsive. If this is affecting your production workloads you may need to consider upgrading to a different instance type or managing your CPU usage more carefully to avoid exhausting your credits.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html
https://repost.aws/knowledge-center/ec2-instance-slow-cpu-not-high
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html
Thanks very much for that answer.
How is this not false advertising, though? It simply means that I can't use the computing power I purchase. I buy/rent 2 CPUs but I can only use 0.4 of them. And nowhere does it say that during checkout. If I enjoy redlining my chips, and I pay for them, it should be my right to do so I think.....
To make matters worse, it seems like Amazon retaliates for using more than 20% CPU by killing the whole instance, requiring a full reboot.
I think this is mind-boggling. It's like buying a car that instantly shuts down, comes to a full stop, and deflates its tires the moment you rev the engine over 1500 RPM. And then not mentioning this "little detail" during the sales process!
I'll email support about this and have them try to explain how that isn't a consumer rights violation. Will update.
I might have been wrong about the punitive incapacitating of instances. I had created this instance off a snapshot from another instance. For reasons beyond my understanding, the destination instance had its default php.ini with resource limits so low it could not operate PHP properly. I guess snapshots are not really snapshots. This definitely contributed to the problem.
I'll have to give this saga a little more time although I still feel it's not OK to not be able to use my CPU's for more than 20% of their capacity.
I was right about the punitive throttling after all.
I now have a live case of how this can damage an application. I ran a composer update command, halfway though, my CPU utilization went from <20% to a mere 47% and Amazon just cut off my instance, killed all my sessions and cut off composer as it was updating code.
How does this makes sense?
相關內容
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前
- AWS 官方已更新 1 年前
You are raising a valid concern Choose non-burstable instances like M5 or C5 for continuous CPU performance. Monitor CPU credits regularly to prevent throttling on burstable instances.