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?

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