Manche Cloud-Datenträger und kleine Servergrößen haben Burst-Credits, mit denen sie kurzzeitig schneller als ihre Basisleistung arbeiten. Dauert eine Lastphase lange und sind die Credits aufgebraucht, sinkt die Geschwindigkeit schlagartig.
Warum Lange Nutzung oberhalb der Basisleistung → Folge Burst-Credits aufgebraucht, Leistung fällt abrupt auf die Basisleistung → Auf dem Bildschirm Jeden Abend beginnt der Lag erst nach einigen Stunden
Server/OS: Datenträger mit garantierter Leistung einsetzen (gp3, Provisioned IOPS), Alarm auf das Credit-Guthaben einrichten, auch das Burst-Limit der Disk-Bandbreite der Instanz und die CPU-Credits prüfen. DB-Systeme: auch DB-Datenträger, einschließlich verwalteter Datenbanken, auf garantierte Leistung umstellen, Alarm auf das Credit-Guthaben einrichten.
Größenordnungen
Ein AWS-gp2-Datenträger mit 100 GB liefert normalerweise 300 IOPS, im Burst 3.000 IOPS, und hält mit vollem Guthaben etwa 30 Minuten durch. gp3 hat keine Credits und liefert immer 3.000. Auch kleine Premium SSDs von Azure laufen mit Credits bis zu 30 Minuten im Burst.
Im Graphen
Plateau am Limit · IOPS, Burst-Credit-Guthaben
Wo nachsehen
In CloudWatch BurstBalance von EBS (gp2, st1, sc1), EBSIOBalance% und EBSByteBalance% der Instanz (einige Instanzen mit Burst) und CPUCreditBalance bei burstfähigen Instanzen prüfen. Bei Azure Metriken zur Nutzung der Burst-Credits wie Data Disk Used Burst IO Credits Percentage prüfen
Spricht dafür
Ab dem Zeitpunkt, an dem das Guthaben gegen 0 fällt, verläuft IOPS (VolumeReadOps, VolumeWriteOps) flach auf Höhe der Basisleistung, VolumeQueueLength und Lag steigen gemeinsam. Beginnt erst, nachdem die Spitzenlast einige Stunden angehalten hat
Spricht dagegen
Alle Guthaben ausreichend, IOPS trotzdem flach: festes Limit von Volume oder Instanz (dk-iops)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch bei intaktem Datenträger zeigt sich bei kleinen virtuellen Servern dasselbe Muster, weil die Disk-Bandbreite der Instanz selbst ein Burst-Limit hat (etwa mindestens 30 Minuten pro Tag). Günstige Server mit CPU-Credits werden ebenfalls auf ihre Basisleistung gebremst, sobald die Credits aufgebraucht sind.
Quellen
Amazon EBS General Purpose SSD volumesAWS Basisleistung von gp2: 3 IOPS pro GiB (mindestens 100), Burst bis 3.000 IOPS über I/O-Credits, 5,4 Millionen Credits reichen für mindestens 30 Minuten. gp3 liefert ohne Burst immer 3.000 IOPS
Managed disk burstingMicrosoft Azure Premium SSD bis P20 mit Credit-basiertem Burst, mit vollem Guthaben 30 Minuten bei maximaler Burst-Geschwindigkeit
Amazon EBS-optimized instance typesAWS Einige Instanzen halten die maximale EBS-Leistung nur 30 Minuten einmal alle 24 Stunden und fallen danach auf die Basisleistung zurück
Standard mode for burstable performance instancesAWS Burstfähige Instanzen im Standardmodus senken die CPU-Auslastung bei aufgebrauchten CPU-Credits auf das Basisniveau (allmählich, ohne abrupten Abfall)
Amazon CloudWatch metrics for Amazon EBSAWS BurstBalance: verbleibende I/O-Credits bei gp2 bzw. Durchsatz-Credits bei st1 und sc1 (%), VolumeReadOps, VolumeWriteOps, VolumeQueueLength
CloudWatch metrics that are available for your instancesAWS EBSIOBalance% und EBSByteBalance%: verbleibende EBS-Credits einiger Instanzen, die einmal alle 24 Stunden 30 Minuten lang im Burst laufen, CPUCreditBalance: verbleibende CPU-Credits burstfähiger Instanzen
Disk metricsMicrosoft Azure Nutzung der Burst-Credits von Datenträgern und VMs (5-Minuten-Intervall), z. B. Data Disk Used Burst IO Credits Percentage