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

Letzte Aktualisierung: 23.09.2021

Ich habe meine Amazon Relational Database Service (Amazon RDS)-Instance, auf der PostgreSQL ausgeführt wird, auf Version 11 oder höher aktualisiert. Warum kann ich in Amazon CloudWatch alle fünf Minuten einen Anstieg der Schreiblatenz beobachten?

Lösung

Bei einer inaktiv genutzten Amazon Relational Database Service (Amazon RDS) for PostgreSQL-Instance stellen Sie möglicherweise alle fünf Minuten einen Anstieg der Amazon CloudWatch-Metrik Schreiblatenz fest. Dieser Anstieg korreliert mit einem Anstieg der Enhanced Monitoring-Metrik Write Total auf ungefähr 64 MB, nachdem Sie auf PostgreSQL Version 11 oder höher aktualisiert haben. Der Wert des Parameters wal_segment_size wechseln nach dem Upgrade auf 64 MB. Diese Latenzspitzen sind bei Version 10 oder früher möglicherweise nicht erkennbar, da der Wert von wal_segment_size 16 MB hier beträgt. Weitere Informationen finden Sie im Update für den 7. September 2018 in der Amazon RDS – Dokumentenhistorie.

Die Konfiguration archive_timeout in RDS für PostgreSQL ist auf 5 Minuten festgelegt. Diese Einstellung bedeutet, dass der Archivierungsvorgang alle fünf Minuten die Write Ahead Logging-Segmente (WAL) kopiert, die im Amazon Simple Storage Service (Amazon S3) archiviert werden sollen. In einem nicht genutzten System ist dieser Kopiervorgang normalerweise die einzige I/O-Operation, weshalb dieser Vorgang in den CloudWatch-Diagrammen möglicherweise auffällig sichtbar ist. In einem ausgelasteten System ist dieses Muster jedoch möglicherweise nicht erkennbar. Angenommen, Sie führen die folgende Workload 30 Minuten lang auf einer db.t3.small-Instance aus, um ein belebtes System auf einer RDS for PostgreSQL-Instance mit einem Amazon Elastic Block Store-Volume (Amazon EBS) mit 20 GB zu simulieren:

#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 Workload können Sie keine Spitzen in der CloudWatch Write Latency-Metrik beobachten.

Angenommen, Sie haben die folgenden Anwendungsfälle:

  • Sie haben eine I/O-Anforderung, deren Abschluss 10 Millisekunden dauert, und neun weitere I/O-Anforderungen, 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-Anforderung, deren Abschluss 10 Millisekunden dauert, Sie haben keine weiteren I/O-Anforderungen. Die durchschnittliche Latenz wird in diesem Fall wie folgt berechnet:
    Durchschnittliche Latenz = 10/1 = 10 Millisekunden

Beide Anwendungsfälle beinhalten dieselbe I/O-Anforderung, die 10 Millisekunden in Anspruch nimmt. Wenn Sie jedoch die durchschnittliche Latenz berechnen, fällt die langsame Anforderung im zweiten Anwendungsfall auf, in dem weniger I/O-Anforderungen zusammen mit der langsamen Anforderung ausgeführt werden. Wenn ein ungenutztes System aufgrund der hohen Blockgröße eine langsame I/O-Anforderung aufweist, wird die Latenz nur aus dieser Anforderung berechnet. In einem ausgelasteten System mit mehreren I/O-Anforderungen, die meisten mit kleineren Blockgrößen, wird die durchschnittliche Latenz aus all diesen Anforderungen berechnet.

In diesen Fällen sehen Sie möglicherweise alle fünf Minuten einen Anstieg der Schreiblatenz in einem nicht genutzten RDS für PostgreSQL-System. Wenn Ihre Datenbank-Instance eine ausgelastete Workload ausführt, sehen Sie diese Spitzen möglicherweise nicht.

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

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

*/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 unbedingt big_file.txt im Befehl durch den Namen Ihrer Datei.

Führen Sie außerdem den folgenden Befehl auf crontab aus, um in der zweiten Amazon EC2-Instance 100 Dateien mit einer Blockgröße von jeweils 8 KB pro Minute zu erstellen:

* * * * * 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 unbedingt small_file.txt im Befehl durch den Namen Ihrer Datei.

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


War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?