Durch die Nutzung von AWS re:Post stimmt du den AWS re:Post Nutzungsbedingungen

Warum sehe ich alle fünf Minuten Schreiblatenzspitzen, nachdem ich meine Amazon RDS für PostgreSQL-Instance auf Version 11 oder höher aktualisiert habe?

Lesedauer: 4 Minute
0

Ich habe meinen Amazon Relational Database Service (Amazon RDS) für PostgreSQL auf Version 11 oder höher aktualisiert. Ich sehe alle fünf Minuten einen Anstieg der Schreiblatenz in Amazon CloudWatch.

Behebung

Bei einer Amazon RDS für PostgreSQL-Instance im Leerlauf stellen Sie möglicherweise alle fünf Minuten einen Anstieg der Schreiblatenz der Amazon CloudWatch-Metrik fest. Dies korreliert mit einem Anstieg der Schreibsumme für die Enhanced Monitoring-Metrik auf etwa 64 MB, nachdem Sie auf PostgreSQL Version 11 oder höher aktualisiert haben. Der Wert des Parameters wal\ _segment\ _size beträgt nach dem Upgrade 64 MB. Diese Spitzen sind in Version 10 oder früher möglicherweise nicht wahrnehmbar, da der Wert von wal\ _segment\ _size 16 MB beträgt. Weitere Informationen finden Sie im Update vom 7. September 2018 unter Amazon RDS – Dokumentenverlauf.

Die Konfiguration archive\ _timeout in Amazon RDS für PostgreSQL ist auf 5 Minuten festgelegt. Mit dieser Einstellung kopiert der Archivierungsvorgang die Write-Ahead Logging (WAL) -Segmente, die archiviert werden sollen, alle fünf Minuten nach Amazon Simple Storage Service (Amazon S3). In einem System im Leerlauf ist dieser Kopiervorgang normalerweise der einzige I/O-Vorgang, sodass dieser Vorgang in den CloudWatch-Diagrammen möglicherweise deutlich dominiert. In einem ausgelasteten System wird dieses Muster jedoch möglicherweise nicht angezeigt. Nehmen wir beispielsweise an, dass Sie den folgenden Workload 30 Minuten lang auf einer db.t3.small-Instance ausführen. Dieses Beispiel simuliert ein ausgelastetes System auf einer RDS for PostgreSQL-Instance mit einem 20 GB großen Amazon Elastic Block Store (Amazon EBS)-Volume:

#pgbench --host=$HOST --username=$USER --port=$PORT --protocol=simple  --progress=2  --client=1 --jobs=1 $DB -T 1800
#pgbench --initialize --fillfactor=90 --scale=100  --port=$PORT --host=$HOST --username=$USER $DB

Bei dieser Arbeitslast werden keine Spitzen in der CloudWatch-Write-Latenz-Metrik angezeigt.

Nehmen wir jedoch an, Sie haben die folgenden Anwendungsfälle:

  • Sie haben eine I/O-Anfrage, deren Abschluss 10 Millisekunden dauert, und neun weitere I/O-Anfragen, deren Abschluss jeweils 1 Millisekunde dauert. Die durchschnittliche Latenz dieser Anfragen wird wie folgt berechnet:
    Durchschnittliche Latenz = (10 + (9\ * 1))/10 = 1,9 Millisekunden
  • Sie haben eine I/O-Anfrage, deren Abschluss 10 Millisekunden dauert, und Sie haben keine anderen I/O-Anfragen. Die durchschnittliche Latenz wird in diesem Fall wie folgt berechnet:
    Durchschnittliche Latenz = 10/1 = 10 Millisekunden

Beide Anwendungsfälle beinhalten dieselbe I/O-Anfrage, deren Fertigstellung 10 Millisekunden dauert. Wenn Sie jedoch die durchschnittliche Latenz berechnen, fällt die langsame Anfrage auf. Dies liegt daran, dass der zweite Anwendungsfall weniger I/O-Anfragen hat, die zusammen mit der langsamen Anfrage ausgeführt werden. Wenn ein System im Leerlauf aufgrund der hohen Blockgröße eine langsame I/O-Anfrage hat, wird die Latenz nur anhand dieser Anfrage berechnet. In einem ausgelasteten System mit mehreren I/O-Anfragen, die meisten mit kleineren Blockgrößen, wird die durchschnittliche Latenz aus all diesen Anfragen berechnet.

In diesen Fällen kann es in einem Amazon RDS für PostgreSQL-System im Leerlauf alle fünf Minuten zu einem Anstieg der Schreiblatenz kommen. Wenn Ihre Datenbank-Instance eine ausgelastete Arbeitslast ausführt, werden Sie diese Spitzen möglicherweise nicht sehen.

Beispiel: Angenommen, Sie haben zwei t2.small Amazon Elastic Compute Cloud (Amazon EC2)-Instances mit jeweils acht GP2-Volumes.

Führen Sie den folgenden Befehl auf crontab aus. Der Befehl erstellt in der ersten Amazon EC2-Instance alle fünf Minuten eine 64-MB-Datei mit einer Blockgröße von 64 MB:

*/5 * * * * dd if=/dev/zero of=/tmp/big_file.txt bs=64MB count=1 oflag=dsync ; rm -rf /tmp/big_file.txt

Hinweis: Ersetzen Sie big\ _file.txt im Befehl durch den Namen Ihrer Datei.

Führen Sie außerdem den folgenden Befehl auf crontab aus. Der Befehl erstellt alle eine Minute 100 Dateien mit einer Blockgröße von jeweils 8 KB in der zweiten Amazon EC2-Instance:

* * * * * for i in {1..100} ; do dd if=/dev/zero of=/tmp/small_file.txt bs=8k count=100 oflag=dsync ; rm -rf /tmp/small_file.txt ; done

Hinweis: Ersetzen Sie small\ _file.txt im Befehl durch den Namen Ihrer Datei.

Möglicherweise stellen Sie fest, dass die zweite EC2-Instance in CloudWatch höhere Writer-Latenzspitzen aufweist als die erste EC2-Instance.

Verwandte Informationen

Bewährte Methoden für die Arbeit mit PostgreSQL

AWS OFFICIAL
AWS OFFICIALAktualisiert vor einem Jahr