1 réponse
- Le plus récent
- Le plus de votes
- La plupart des commentaires
2
Hi,
I've seen cases for the same, because this volume was GP2 earlier, the BurstBalance metric is still reported to CloudWatch. BurstBalance is only valid for gp2,st1 and sc1 volume types and also depends upon the volume specifications, like size.
Ideally the metric shouldn't affect the performance even if the balance drops, you can ignore the metric.
However, If you are experiencing performance degradation + able to see the credits drop in cloudwatch + in gp3, you can open up a case with support to verify the GP3 state of the volumes internally.
Contenus pertinents
- demandé il y a un an
- demandé il y a 3 mois
- demandé il y a un an
- demandé il y a un mois
AWS OFFICIELA mis à jour il y a 2 ans- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 3 ans
- AWS OFFICIELA mis à jour il y a 10 mois
This is interesting! We have the exact same case. A volume that was gp2 earler and got converted to gp3. Our EBSByteBalance% is still visible and dropping despite the sum of read and write throughput only reaching around 5 to 7 MiB/s so well within the specified baseline of the gp3 volume. The problem is that or DB restarts once the credits reach zero. This has happened several times over the last few days and while it's only a testing DB it's still annoying as we are currently filling up the DB with data and need to restart those jobs after every DB reboot... So in this case I will open a support ticket as all my efforts are doomed to fail if it is indeed a bug...