Freigeben über

Problembehandlung bei hoher IOPS-Auslastung in Azure Database for PostgreSQL – Flexibler Server

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Flexibler Server

In diesem Artikel wird gezeigt, wie Sie die Grundursache einer hohen IOPS-Auslastung schnell identifizieren und mit welchen möglichen Abhilfemaßnahmen Sie die IOPS-Auslastung bei Verwendung von Azure Database for PostgreSQL – Flexible Server steuern können.

In diesem Artikel werden folgende Vorgehensweisen behandelt:

  • Informationen zu Problembehandlungsleitfäden zum Identifizieren und Abrufen von Empfehlungen zur Entschärfung von Ursachen.
  • Verwenden von Tools, mit denen Sie eine hohe E/A-Auslastung (Eingabe/Ausgabe) ermitteln können, z. B. Azure-Metriken, Abfragespeicher und pg_stat_statements.
  • Identifizieren von Grundursachen, z. B. zeitintensive Abfragen, Prüfpunktdauer, störender Prozess des Autovacuum-Daemons und eine hohe Speicherauslastung.
  • Auflösen einer hohen E/A-Auslastung mithilfe von Explain Analyze, Optimieren von prüfpunktbezogenen Serverparametern und des Autovacuum-Daemons.

Leitfäden zur Problembehandlung

In den Problembehandlungsleitfäden für Funktionen, die im Azure Database for PostgreSQL – Flexible Server-Portal verfügbar sind, können Sie die wahrscheinliche Ursache und Empfehlungen für das Entschärfungsszenario mit hoher IOPS-Auslastung finden. Informationen dazu, wie Sie die Problembehandlungsleitfäden einrichten, finden Sie unter Einrichten von Problembehandlungsleitfäden.

Tools zum Ermitteln einer hohen E/A-Auslastung

Betrachten Sie die folgenden Tools zur Identifizierung einer hohen E/A-Auslastung.

Azure-Metriken

Azure-Metriken sind ein guter Ausgangspunkt, um die E/A-Auslastung für ein bestimmtes Datum und einen bestimmten Zeitraum zu prüfen. Metriken enthalten Informationen zur Zeitspanne, in der die E/A-Auslastung hoch ausfällt. Vergleichen Sie die Diagramme der Schreib-IOPS, der Lese-IOPS, des Lesedurchsatzes und des Schreibdurchsatzes, um herauszufinden, wann die Workload eine hohe E/A-Auslastung verursacht hat. Für die proaktive Überwachung können Sie Warnungen für die Metriken konfigurieren. Eine detaillierte Anleitung finden Sie unter Azure-Metriken.

Abfragespeicher

Das Abfragespeicher-Feature erfasst automatisch den Verlauf von Abfragen sowie Laufzeitstatistiken und bewahrt diese auf, damit Sie sie später überprüfen können. Die Daten werden dabei so nach der Zeit aufgeteilt, dass Sie zeitliche Nutzungsmuster erkennen können. Die Daten für alle Benutzer, Datenbanken und Abfragen werden in einer Datenbank namens azure_sys in der Azure Database for PostgreSQL – Flexible Server-Instanz gespeichert. Schrittweise Anleitungen finden Sie unter Überwachen der Leistung mit dem Abfragespeicher.

Mit der folgenden Anweisung können Sie die fünf SQL-Anweisungen mit der höchsten E/A-Auslastung anzeigen:

select * from query_store.qs_view qv where is_system_query is FALSE
order by blk_read_time + blk_write_time  desc limit 5;

Die Erweiterung „pg_stat_statements“

Die Erweiterung pg_stat_statements hilft, Abfragen zu ermitteln, die E/A auf dem Server nutzen.

Mit der folgenden Anweisung können Sie die fünf SQL-Anweisungen mit der höchsten E/A-Auslastung anzeigen:

SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY blk_read_time + blk_write_time desc
LIMIT 5;

Hinweis

Wenn Sie den Abfragespeicher oder „pg_stat_statements“ verwenden, damit die Spalten „blk_read_time“ und „blk_write_time“ aufgefüllt werden, müssen Sie den Serverparameter track_io_timing aktivieren. Weitere Informationen zu track_io_timing finden Sie unter Serverparameter.

Ermitteln von Grundursachen

Wenn die E/A-Auslastung im Allgemeinen hoch ausfällt, könnte dies folgende Grundursachen haben:

Lang andauernde Transaktionen

Zeitintensive Transaktionen können E/A-Ressourcen nutzen, die zu einer hohen E/A-Auslastung führen können.

Die folgende Abfrage hilft beim Ermitteln der zeitintensivsten Verbindungen:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

Prüfpunktdauern

Eine hohe E/A-Auslastung kann auch auftreten, wenn ein Prüfpunkt zu häufig auftritt. Eine Möglichkeit, dies zu identifizieren, besteht darin, die Azure Database for PostgreSQL – Flexible Serverprotokolldatei auf den folgenden Protokolltext zu überprüfen: „LOG: Prüfpunkte treten zu häufig auf.“

Sie könnten auch einen Ansatz verwenden, bei dem periodische Momentaufnahmen von pg_stat_bgwriter mit einem Zeitstempel gespeichert werden. Mithilfe der gespeicherten Momentaufnahmen können Sie das durchschnittliche Prüfpunktintervall, die Anzahl der angeforderten Prüfpunkte und die Anzahl der geplanten Prüfpunkte berechnen.

Störender Prozess des Autovacuum-Daemons

Führen Sie die folgende Abfrage aus, um Autovacuum zu überwachen:

SELECT schemaname, relname, n_dead_tup, n_live_tup, autovacuum_count, last_vacuum, last_autovacuum, last_autoanalyze, autovacuum_count, autoanalyze_count FROM pg_stat_all_tables WHERE n_live_tup > 0;

Mit der Abfrage wird überprüft, wie häufig die Tabellen in der Datenbank geleert werden.

  • last_autovacuum: Datum und Uhrzeit der letzten Autovacuum-Ausführung für die Tabelle.
  • autovacuum_count: Die Häufigkeit, mit der die Tabelle geleert wurde.
  • autoanalyze_count: Die Häufigkeit der Tabellenanalyse.

Auflösen einer hohen E/A-Auslastung

Um eine hohe E/A-Auslastung aufzulösen, können Sie eine der folgenden drei Methoden verwenden.

Befehl EXPLAIN ANALYZE

Nachdem Sie die Abfrage ermittelt haben, die eine hohe E/A-Auslastung verursacht, verwenden Sie EXPLAIN ANALYZE, um die Abfrage weiter zu untersuchen und zu optimieren. Weitere Informationen zum Befehl EXPLAIN ANALYZE finden Sie im EXPLAIN-Plan.

Beenden zeitintensiver Transaktionen

Zeitintensive Transaktionen können optional beendet werden.

Um die Prozess-ID (PID) einer Sitzung zu beenden, müssen Sie die PID mithilfe der folgenden Abfrage ermitteln:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

Sie können auch nach anderen Eigenschaften wie usename (Benutzername) oder datname (Datenbankname) filtern.

Wenn Sie die PID der Sitzung ermittelt haben, können Sie sie mithilfe der folgenden Abfrage beenden:

SELECT pg_terminate_backend(pid);

Optimieren von Serverparametern

Falls Sie feststellen, dass ein Prüfpunkt zu häufig auftritt, erhöhen Sie den Serverparameter max_wal_size, bis die meisten Prüfpunkte zeitgesteuert sind und nicht mehr anforderungsgesteuert. Am Ende sollten mindestens 90 % zeitbasiert sein, und das Intervall zwischen zwei Prüfpunkten sollte nahe am checkpoint_timeout-Wert liegen, der auf dem Server festgelegt ist.

  • max_wal_size: Zu Spitzenzeiten darf der max_wal_size-Wert erreicht werden. Gehen Sie wie folgt vor, um einen Wert zu erreichen:

    1. Führen Sie die folgende Abfrage aus, um den aktuellen WAL-LSN-Wert abzurufen, und notieren Sie dann das Ergebnis:

      select pg_current_wal_lsn();

    2. Warten Sie checkpoint_timeout Sekunden. Führen Sie die folgende Abfrage aus, um den aktuellen WAL-LSN-Wert abzurufen, und notieren Sie dann das Ergebnis:

      select pg_current_wal_lsn();

    3. Führen Sie die folgende Abfrage aus, die die beiden Ergebnisse verwendet, um den Unterschied in Gigabyte (GB) zu überprüfen:

      select round (pg_wal_lsn_diff ('LSN value when run second time', 'LSN value when run first time')/1024/1024/1024,2) WAL_CHANGE_GB;

  • checkpoint_completion_target: Als Wert hat sich 0,9 bewährt. Ein Wert von 0,9 für ein checkpoint_timeout von 5 Minuten gibt z. B. an, dass das Ziel für den Abschluss eines Prüfpunkts 270 Sekunden [0,9 × 300 Sekunden] beträgt. Der Wert 0,9 sorgt für eine relativ konsistente E/A-Auslastung. Ein aggressiver Wert von checkpoint_completion_target könnte zu einer höheren E/A-Auslastung auf dem Server führen.

  • checkpoint_timeout: Sie können den checkpoint_timeout-Wert gegenüber dem Standardwert erhöhen, der auf dem Server festgelegt ist. Beachten Sie, dass eine Erhöhung des Werts auch die Zeit für die Wiederherstellung nach einem Absturz verlängert.

Optimieren von Autovacuum zum Verringern der Unterbrechungen

Weitere Informationen zur Überwachung und Optimierung in Szenarien, in denen Autovacuum zu störend ist, finden Sie unter Autovacuum-Tuning.

Vergrößern des Speichers

Die Erhöhung des Speichers hilft beim Hinzufügen weiterer IOPS zum Server. Weitere Informationen zu Speicher und den zugehörigen IOPS finden Sie unter Compute- und Speicheroptionen.

Zugehöriger Inhalt