Wir haben gerade einen Snapshot einer unserer Postgres-Datenbanken in RDS wiederhergestellt. Die Instanz war früher eine db.t2.xlarge und wir haben sie in eine db.r5.large umgewandelt. Sie verfügt über ein GP2-SSD-Volumen von 100 GB.
r5.large-Instanzen sollen „EBS-optimiert“ sein, dennoch habe ich überraschend niedrige Lese-IOPS, wie die Grafik unten zeigt.
Dies ist das Ergebnis einer SELECT COUNT(*)großen Tabelle. Bei derselben Abfrage erreicht unsere t2.xlarge-Instanz problemlos 1250 IOPS. Es scheint auch sonst keinen Engpass zu geben: Die CPU-Auslastung liegt bei etwa 0 % und es ist ausreichend Speicher verfügbar.
Darüber hinaus scheint die AWS-Dokumentation darauf hinzudeuten, dass ich für ein Volume dieser Größe mit mindestens 300 IOPS rechnen könnte:
GP2 ist darauf ausgelegt, Latenzen im einstelligen Millisekundenbereich zu bieten und eine konstante Basisleistung von 3 IOPS/GB (mindestens 100 IOPS) bis maximal 16.000 IOPS zu liefern.
(sehenhttps://aws.amazon.com/ebs/features/)
Warum ist r5.large so langsam?
Antwort1
Nun, es scheint, dass die IOPS jetzt wieder vernünftige Werte erreicht haben. Es könnte mit IO-Guthaben zusammenhängen oder damit, dass der Snapshot noch wiederhergestellt wird ... nicht sicher.
Antwort2
IOPS hängen von der Festplattengröße ab. Wenn Sie die Festplattengröße erhöhen, erhöhen sich auch die verfügbaren IOPS.