LWLock:pg_stat_statements - Amazon Aurora
Unterstützte Engine-VersionenKontextWahrscheinliche Ursachen für erhöhte WartezeitenAktionen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

LWLock:pg_stat_statements

Das LWLock Warteereignis:PG_STAT_STATEMENTS tritt ein, wenn die Erweiterung die Hashtabelle, die SQL-Anweisungen verfolgt, exklusiv sperrt. pg_stat_statements Dies passiert in den folgenden Szenarien:

  • Wenn die Anzahl der verfolgten Anweisungen den konfigurierten pg_stat_statements.max Parameterwert erreicht und Platz für weitere Einträge geschaffen werden muss, sortiert die Erweiterung die Anzahl der Aufrufe, entfernt die 5% der am wenigsten ausgeführten Anweisungen und füllt den Hash erneut mit den verbleibenden Einträgen auf.

  • When pg_stat_statements führt eine garbage collection Operation an der pgss_query_texts.stat Datei auf der Festplatte durch und schreibt die Datei neu.

Unterstützte Engine-Versionen

Diese Warteereignisinformationen werden für alle Versionen von unterstützt.

Kontext

Grundlegendes zur Erweiterung pg_stat_statements — Die Erweiterung pg_stat_statements verfolgt Statistiken zur Ausführung von SQL-Anweisungen in einer Hashtabelle. Die Erweiterung verfolgt SQL-Anweisungen bis zu dem durch den Parameter definierten Grenzwert. pg_stat_statements.max Dieser Parameter bestimmt die maximale Anzahl von Anweisungen, die verfolgt werden können, was der maximalen Anzahl von Zeilen in der Ansicht pg_stat_statements entspricht.

Persistenz von Anweisungsstatistiken — Die Erweiterung behält die Anweisungsstatistiken bei jedem Neustart der Instanz bei, indem sie:

  • Daten in eine Datei namens pg_stat_statements.stat schreiben

  • Verwendung des Parameters pg_stat_statements.save zur Steuerung des Persistenzverhaltens

Wenn pg_stat_statements.save auf Folgendes gesetzt ist:

  • on (Standard): Statistiken werden beim Herunterfahren gespeichert und beim Serverstart erneut geladen

  • aus: Statistiken werden weder beim Herunterfahren gespeichert noch beim Serverstart neu geladen

Textspeicher für Abfragen — Die Erweiterung speichert den Text nachverfolgter Abfragen in einer Datei mit dem Namenpgss_query_texts.stat. Diese Datei kann auf das Doppelte der durchschnittlichen Größe aller verfolgten SQL-Anweisungen anwachsen, bevor die Speicherbereinigung erfolgt. Die Erweiterung erfordert eine exklusive Sperre für die Hashtabelle während der Bereinigungsvorgänge und beim Umschreiben pgss_query_texts.stat der Datei.

Prozess zur Freigabe von Kontoauszügen — Wenn die Anzahl nachverfolgter Kontoauszüge das pg_stat_statements.max Limit erreicht und neue Kontoauszüge nachverfolgt werden müssen, erfolgt die Erweiterung wie folgt:

  • Erhält eine exklusive Sperre (:pg_stat_statementsLWLock) für die Hashtabelle.

  • Lädt vorhandene Daten in den lokalen Speicher.

  • Führt eine Schnellsortierung auf der Grundlage der Anzahl der Aufrufe durch.

  • Entfernt die am wenigsten aufgerufenen Anweisungen (unterste 5%).

  • Füllt die Hashtabelle erneut mit den verbleibenden Einträgen auf.

Überwachung der Freigabe von Anweisungen — In PostgreSQL 14 und höher können Sie die Freigabe von Anweisungen mithilfe der Ansicht pg_stat_statements_info überwachen. Diese Ansicht enthält eine Dealloc-Spalte, in der angezeigt wird, wie oft die Zuweisung von Anweisungen aufgehoben wurde, um Platz für neue Anweisungen zu schaffen

Wenn die Freigabe von Anweisungen häufig erfolgt, führt dies zu einer häufigeren Garbage-Collection der Datei auf der pgss_query_texts.stat Festplatte.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Zu den typischen Ursachen für erhöhte LWLock:pg_stat_statements Wartezeiten gehören:

  • Eine Zunahme der Anzahl von eindeutigen Abfragen, die von der Anwendung verwendet werden.

  • Der pg_stat_statements.max Parameterwert ist klein im Vergleich zur Anzahl der verwendeten eindeutigen Abfragen.

Aktionen

Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Sie können LWLock:pg_stat_statements Ereignisse mithilfe von Amazon RDS Performance Insights oder durch Abfragen der Ansicht pg_stat_activity identifizieren.

Passen Sie die folgenden pg_stat_statements Parameter an, um das Tracking-Verhalten zu steuern und zu LWLock reduzieren:pg_stat_-Anweisungen warten auf Ereignisse.

Deaktivieren Sie den Parameter pg_stat_statements.track

Wenn sich das LWLock Wait-Event:pg_stat_statements negativ auf die Datenbankleistung auswirkt und eine schnelle Lösung erforderlich ist, bevor die Ansicht weiter analysiert wird, um die Ursache pg_stat_statements zu ermitteln, kann der Parameter deaktiviert werden, indem er auf gesetzt wird. pg_stat_statements.track none Dadurch wird die Erfassung von Kontoauszugsstatistiken deaktiviert.

Erhöhen Sie den Parameter pg_stat_statements.max

Erhöhen Sie den Wert des Parameters, um die Deallokation zu reduzieren und die Garbage-Collection der pgss_query_texts.stat Datei auf der Festplatte zu minimieren. pg_stat_statements.max Der Standardwert ist 5,000.

Anmerkung

Der pg_stat_statements.max Parameter ist statisch. Sie müssen Ihre DB-Instance neu starten, um Änderungen an diesem Parameter zu übernehmen.

Deaktivieren Sie den Parameter pg_stat_statements.track_utility

Sie können die Ansicht pg_stat_statements analysieren, um festzustellen, welche Dienstprogrammbefehle die meisten Ressourcen verbrauchen, die von erfasst werden. pg_stat_statements

Der pg_stat_statements.track_utility Parameter steuert, ob das Modul Dienstprogrammbefehle verfolgt, zu denen alle Befehle außer SELECT, INSERT, UPDATE, DELETE und MERGE gehören. Dieser Parameter ist standardmäßig auf on festgelegt.

Wenn Ihre Anwendung beispielsweise viele Savepoint-Abfragen verwendet, die von Natur aus einzigartig sind, kann dies die Deallocation von Anweisungen erhöhen. Um dieses Problem zu beheben, können Sie den pg_stat_statements.track_utility Parameter deaktivieren, sodass Savepoint-Abfragen nicht mehr verfolgt pg_stat_statements werden.

Anmerkung

Der pg_stat_statements.track_utility Parameter ist ein dynamischer Parameter. Sie können seinen Wert ändern, ohne Ihre Datenbankinstanz neu zu starten.

Beispiel für eindeutige Speicherpunktabfragen in pg_stat_statements

                     query                       |       queryid       
-------------------------------------------------+---------------------
 SAVEPOINT JDBC_SAVEPOINT_495701                 | -7249565344517699703
 SAVEPOINT JDBC_SAVEPOINT_1320                   | -1572997038849006629
 SAVEPOINT JDBC_SAVEPOINT_26739                  |  54791337410474486
 SAVEPOINT JDBC_SAVEPOINT_1294466                |  8170064357463507593
 ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016      | -33608214779996400
 SAVEPOINT JDBC_SAVEPOINT_14185                  | -2175035613806809562
 SAVEPOINT JDBC_SAVEPOINT_45837                  | -6201592986750645383
 SAVEPOINT JDBC_SAVEPOINT_1324                   |  6388797791882029332

PostgreSQL 17 führt mehrere Verbesserungen für die Befehlsverfolgung von Dienstprogrammen ein:

  • Savepoint-Namen werden jetzt als Konstanten angezeigt.

  • Die globale Transaktion IDs (GIDs) von zweiphasigen Commit-Befehlen wird jetzt als Konstanten angezeigt.

  • Die Namen von DEALLOCATE-Anweisungen werden als Konstanten angezeigt.

  • CALL-Parameter werden jetzt als Konstanten angezeigt.