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.
Unbegrenzte Anzahl von Datenbank-Warteereignissen
Die folgenden Warteereignisse gelten für Aurora PostgreSQL Limitless Database. Sie können diese Warteereignisse überwachen, um Engpässe bei der Verarbeitung von Aurora PostgreSQL Limitless Database zu identifizieren.
Themen
AuroraLimitless: Ereignis DistributedCommitPrepareThrottle abwarten
AuroraLimitless: Ereignis PreparedTransactionResolution abwarten
AuroraLimitless: Ereignis SendPreparedTransactionOutcome abwarten
AuroraLimitless: Ereignis ReaderSnapshotClockBarrier abwarten
AuroraLimitless: Ereignis GatherDistributedDeadlockGraph abwarten
AuroraLimitless: Ereignis DistributedDeadlockDetection abwarten
AuroraLimitless: Ereignis DistributedTransactionMonitorGather abwarten
AuroraLimitlessActivity: Ereignis AdminTaskSchedulerMain abwarten
AuroraLimitlessActivity: Ereignis AdminTaskExecutorMain abwarten
AuroraLimitlessActivity: Ereignis AdminTaskMonitorMain abwarten
AuroraLimitlessActivity: Ereignis DatabaseCleanupMonitorMain abwarten
AuroraLimitlessActivity: Ereignis TopologyCleanupMonitorMain abwarten
AuroraLimitlessActivity: Ereignis ToplogyChangeMonitorMain abwarten
AuroraLimitlessActivity: Ereignis DistributedTransactionMonitorMain abwarten
AuroraLimitlessActivity: Ereignis GlobalVacuumMonitorMain abwarten
TwophaseFilePoolWrite IO: Warteereignis
Es wird auf den Schreibvorgang einer zweiphasigen Statusdatei innerhalb des zweiphasigen Zustandsdateipools gewartet. Dies ist ein Aurora-spezifisches Ereignis.
Ursachen
Prozesse, die einen PREPARED TRANSACTION
Befehl ausführen, einschließlich Teilnehmern an einer verteilten Transaktion mit Limitless Database, müssen den Transaktionsstatus in einer zweiphasigen Datei beibehalten. Aurora verwendet einen Dateipool, um die Leistung dieses Vorgangs zu verbessern.
Aktion
Da es sich um einen synchronen I/O-Schreibvorgang handelt, hat eine hohe Latenz in diesem Fall ähnliche Ursachen IO:XactSync
und kann auf dieselbe Weise untersucht werden. Wenn Sie Limitless Database verwenden, müssen Sie möglicherweise die Anzahl der ausgeführten verteilten Transaktionen reduzieren.
IO: Ereignis TwophaseFilePoolRead abwarten
Es wird auf das Lesen einer zweiphasigen Statusdatei im zweiphasigen Zustandsdateipool gewartet.
Ursachen
Prozesse, die einen COMMIT PREPARED
Befehl für eine zuvor vorbereitete Transaktion ausführen, einschließlich Teilnehmer an einer verteilten Transaktion mit Limitless Database, müssen möglicherweise den zuvor persistierten Transaktionsstatus aus einer zweiphasigen Datei lesen. Aurora verwendet einen Dateipool, um die Leistung dieses Vorgangs zu verbessern.
Aktion
Dies ist ein I/O-Lesevorgang. Daher hat eine hohe Latenz bei diesem Ereignis ähnliche Ursachen IO:DataFileRead
und kann mit denselben untersucht werden. Wenn Sie Limitless Database verwenden, müssen Sie möglicherweise die Anzahl der ausgeführten verteilten Transaktionen reduzieren.
AuroraLimitless:Connect Wait-Ereignis
Der Prozess wartet darauf, dass eine Verbindung zu einem anderen Knoten im Cluster hergestellt wird.
Ursachen
Verbindungen werden zwischen Prozessen und Remoteknoten hergestellt, um Abfragen und verteilte Transaktionen auszuführen und durchzuführen DDLs.
Aktion
Reduzieren Sie die Anzahl der gleichzeitigen Verbindungen zum Cluster oder optimieren Sie die Verwendung von Cross-Shard-Abfragen.
AuroraLimitless: Ereignis AsyncConnect abwarten
Dieses Ereignis ähneltConnect
, stellt aber einen Prozess dar, der darauf wartet, dass parallel Verbindungen zu einer Gruppe von Knoten hergestellt werden.
Ursachen
Der parallele Verbindungsaufbau erfolgt am häufigsten bei der Ausführung von DDL-Anweisungen.
Aktion
Reduzieren Sie die Anzahl der DDL-Anweisungen oder kombinieren Sie mehrere DDLs in derselben Sitzung, um die Wiederverwendung von Verbindungen zu verbessern.
AuroraLimitless: Ereignis RemoteStatementSetup abwarten
Der Prozess wartet auf die Einrichtung zur Ausführung von Abfragen aus der Ferne, z. B. auf das Öffnen oder Schließen des Cursors oder die Erstellung einer vorbereiteten Anweisung.
Ursachen
Dieses Warteereignis nimmt mit der Anzahl der Scans in Shard-Tabellen zu, bei denen die Anweisung nicht für ein einzelnes Shard optimiert werden konnte.
Aktion
Optimieren Sie Abfragen, um die Anzahl der Scanvorgänge zu reduzieren oder die Eignung für die Single-Shard-Optimierung zu erhöhen.
AuroraLimitlessOptimieren Sie DDLExecution Abfragen, um die Anzahl der Scanvorgänge zu reduzieren oder die Eignung für die Single-Shard-Optimierung zu erhöhen. ----SEP----:Remote Wait Event
Der Prozess wartet darauf, dass ein Remote-DDL-Befehl abgeschlossen wird.
Ursachen
Wenn Sie einen DDL-Befehl für eine DB-Shard-Gruppe ausgeben, muss er an andere Router- und Shard-Knoten verteilt werden, bevor der Vorgang bestätigt wird. Einige DDL-Operationen können lange dauern, da Daten an Schemaänderungen angepasst werden müssen.
Aktion
Identifizieren Sie DDL-Befehle mit langer Laufzeit, damit Sie sie optimieren können.
AuroraLimitless: Ereignis RemoteStatementExecution abwarten
Ein Prozess wartet darauf, dass ein Fernbefehl beendet wird.
Ursachen
Ein SQL-Befehl wird auf einem Remote-Knoten ausgeführt. Dieses Ereignis tritt häufig bei der internen Kommunikation auf, z. B. bei auto_analyze
Heartbeat-Prüfungen.
Aktion
Identifizieren Sie Befehle mit langer Laufzeit mithilfe der Ansicht limitless_stat_statements. In vielen Fällen ist dies ein erwartetes Ereignis, insbesondere bei Mitarbeitern im Hintergrund oder bei internen Prozessen, und es sind keine Maßnahmen erforderlich.
AuroraLimitless: Ereignis FetchRemoteResults abwarten
Ein Prozess wartet darauf, Zeilen von einem entfernten Knoten abzurufen.
Ursachen
Dieses Warteereignis kann zunehmen, wenn eine große Anzahl von Zeilen aus einer entfernten Tabelle abgerufen wird, z. B. aus einer Sharded- oder Referenztabelle.
Aktion
Identifizieren Sie nicht optimierte SELECT
Abfragen mithilfe der Ansicht. limitless_stat_statements
Optimieren Sie Abfragen, um nur die erforderlichen Daten abzurufen. Sie können den rds_aurora.limitless_maximum_adaptive_fetch_size
Parameter auch anpassen.
AuroraLimitless: Ereignis AsyncGetInitialResponse abwarten
Der Prozess wartet auf eine erste Antwort, wenn der Pipeline-Modus bei der Abfrageausführung verwendet wird.
Ursachen
Dies tritt normalerweise bei der Router-zu-Shard-Ausführung bei Abfragen mit Single-Shard-Datenplatzierung auf und ist ein erwarteter Teil der normalen Ausführung.
Aktion
Es sind keine weiteren Maßnahmen erforderlich.
AuroraLimitless: Ereignis abwarten AsyncGetNextResponse
Der Prozess wartet auf zusätzliche Antworten, wenn der Pipeline-Modus bei der Abfrageausführung verwendet wird.
Ursachen
Dies tritt normalerweise bei der Router-zu-Shard-Ausführung bei Abfragen mit Single-Shard-Datenplatzierung auf und ist ein erwarteter Teil der normalen Ausführung.
Aktion
Es sind keine weiteren Maßnahmen erforderlich.
AuroraLimitless: Ereignis abwarten AbortedCommandCleanup
Der Prozess wartet auf das Ergebnis einer Remote-Bereinigungsabfrage. Bereinigungsabfragen werden an Shard-Knoten gesendet, um sie nach dem Beenden einer verteilten Transaktion wieder in einen geeigneten Zustand zu versetzen.
Ursachen
Eine Transaktionsbereinigung erfolgt, wenn eine Transaktion abgebrochen wird, entweder weil ein Fehler gefunden wurde oder weil ein Benutzer einen expliziten ABORT-Befehl ausgegeben oder die laufende Abfrage abgebrochen hat.
Aktion
Untersuchen Sie die Ursache für den Abbruch der Transaktion.
AuroraLimitless: Ereignis DistributedCommitPrepare abwarten
Der Prozess führt eine verteilte Transaktion durch und wartet darauf, dass alle Teilnehmer den Befehl prepare bestätigen.
Ursachen
Transaktionen, die mehrere Knoten modifizieren, müssen einen verteilten Commit durchführen. Eine lange Wartezeit DistributedCommitPrepare
kann durch lange Wartezeiten bei der IO:TwophaseFilePoolWrite
Veranstaltung auf den teilnehmenden Knoten verursacht werden.
Aktion
Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie IO:TwophaseFilePoolWrite
Ereignisse in anderen Knoten des Clusters.
AuroraLimitless: Ereignis DistributedCommit abwarten
Der Prozess schreibt eine verteilte Transaktion fest und wartet darauf, dass der Hauptteilnehmer den Commit-Befehl bestätigt.
Ursachen
Transaktionen, die mehrere Knoten modifizieren, müssen einen verteilten Commit durchführen. Eine lange Wartezeit DistributedCommit
könnte auf lange Wartezeiten beim IO:XactSync
Hauptteilnehmer zurückzuführen sein.
Aktion
Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie IO:XactSync
Ereignisse in anderen Knoten des Clusters.
AuroraLimitless: Ereignis DistributedCommitPrepareThrottle abwarten
Der Prozess versucht, eine verteilte Transaktion vorzubereiten, und wird aufgrund vorhandener vorbereiteter Transaktionen nur eingeschränkt.
Ursachen
Transaktionen, die mehrere Knoten modifizieren, müssen einen verteilten Commit durchführen. Die Teilnehmer an diesen Transaktionen müssen im Rahmen des Commit-Protokolls einen Vorbereitungsvorgang durchführen. Aurora begrenzt die Anzahl der gleichzeitigen Prepares, und wenn dieses Limit überschritten wird, wartet der Prozess auf das DistributedCommitPrepareThrottle
Ereignis.
Aktion
Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie IO:TwophaseFilePoolWrite
Ereignisse, da eine längere Verweildauer dieser Ereignisse dazu führen kann, dass sich bereits vorbereitete Transaktionen ansammeln, was zu einer Einschränkung neuer Vorbereitungsversuche führen kann.
AuroraLimitless: Ereignis PreparedTransactionResolution abwarten
Der Prozess ist auf ein Tupel gestoßen, das durch eine verteilte Transaktion verändert wurde und sich im Status „Vorbereitet“ befindet. Der Prozess muss ermitteln, ob die verteilte Transaktion in ihrem Snapshot sichtbar wird.
Ursachen
Transaktionen, die mehrere Knoten modifizieren, müssen einen verteilten Commit durchführen, der eine Vorbereitungsphase beinhaltet. Eine hohe Anzahl verteilter Transaktionen oder eine erhöhte Latenz bei verteilten Commits können dazu führen, dass andere Prozesse auf das PreparedTransactionResolution
Wait-Ereignis stoßen.
Aktion
Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie Ereignisse im Zusammenhang mit verteilten Commits, da eine längere Dauer dieser Ereignisse die Latenz im Commit-Pfad verteilter Transaktionen erhöhen könnte. Möglicherweise möchten Sie auch die Netzwerk- und CPU-Auslastung untersuchen.
AuroraLimitless: Ereignis SendPreparedTransactionOutcome abwarten
Der Prozess wird auf einem Knoten ausgeführt, der eine verteilte Transaktion koordiniert, und ein anderer Prozess hat den Status dieser Transaktion abgefragt, oder der Prozess hat eine verteilte Transaktion festgeschrieben und sendet das Ergebnis an die Teilnehmer.
Ursachen
Prozesse, bei denen das PreparedTransactionResolution
Warteereignis auftritt, fragen den Transaktionskoordinator ab. Die Antwort des Transaktionskoordinators wird angezeigt. SendPreparedTransactionOutcome
Aktion
Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie Ereignisse IO:TwophaseFilePoolWrite
und IO:TwophaseFilePoolRead
Ereignisse im Zusammenhang mit verteilten Commits, da diese Ereignisse die Latenz im Commit-Pfad verteilter Transaktionen erhöhen könnten. Möglicherweise möchten Sie auch die Netzwerk- und CPU-Auslastung untersuchen.
AuroraLimitless: Ereignis CommitClockBarrier abwarten
Der Prozess schreibt eine Transaktion fest und muss warten, um sicherzustellen, dass die zugewiesene Festschreibungszeit für alle Knoten im Cluster garantiert in der Vergangenheit liegt.
Ursachen
Die Auslastung der CPU oder des Netzwerks kann zu einer erhöhten Taktabweichung führen, was dazu führen kann, dass für dieses Warteereignis Zeit aufgewendet wird.
Aktion
Untersuchen Sie die CPU- oder Netzwerkauslastung in Ihrem Cluster.
AuroraLimitless: Ereignis SnapshotClockBarrier abwarten
Der Prozess hat eine Snapshot-Zeit von einem anderen Knoten mit einer Uhr in der future empfangen und wartet darauf, dass seine eigene Uhr diese Zeit erreicht.
Ursachen
Dies tritt normalerweise auf, nachdem der Prozess Ergebnisse einer Funktion erhalten hat, die auf einen Shard heruntergeschoben wurde, und es zu einer Taktverschiebung zwischen den Knoten kommt. Ein Ausfall der CPU oder des Netzwerks kann zu einer erhöhten Taktabweichung führen, was wiederum dazu führen kann, dass für dieses Warteereignis Zeit aufgewendet wird.
Aktion
Untersuchen Sie den CPU- oder Netzwerkstatus in Ihrem Cluster.
AuroraLimitless: Ereignis ReaderSnapshotClockBarrier abwarten
Dieses Ereignis tritt auf gelesenen Knoten auf. Der Prozess wartet darauf, dass der Leseknoten den Schreibstream wiedergibt, sodass alle Schreibvorgänge, die vor dem Zeitpunkt des Prozess-Snapshots stattfanden, übernommen wurden.
Ursachen
Eine Zunahme der Verzögerung bei Aurora-Replikaten kann in diesem Fall zu längeren Wartezeiten führen.
Aktion
Untersuchen Sie die Verzögerung bei der Aurora-Replikation.
AuroraLimitless: Ereignis GatherDistributedDeadlockGraph abwarten
Der Prozess kommuniziert mit anderen Knoten, um im Rahmen der Erkennung verteilter Deadlocks Sperrgraphen zu sammeln.
Ursachen
Wenn ein Prozess auf eine Sperre wartet, führt er eine Prüfung auf verteilte Deadlocks durch, nachdem er länger gewartet hat. rds_aurora.limitless_distributed_deadlock_timeout
Aktion
Untersuchen Sie die Ursachen für Sperrkonflikte in Ihrer Anwendung und ziehen Sie eine Optimierung in Betracht. rds_aurora.limitless_distributed_deadlock_timeout
AuroraLimitless: Ereignis DistributedDeadlockDetection abwarten
Der Prozess kommuniziert mit anderen Knoten, um einen verteilten Deadlock zu erkennen.
Ursachen
Wenn ein Prozess auf eine Sperre wartet, führt er eine Prüfung des verteilten Deadlocks durch, nachdem er länger gewartet hat. rds_aurora.limitless_distributed_deadlock_timeout
Aktion
Untersuchen Sie die Ursachen für Sperrkonflikte in Ihrer Anwendung und ziehen Sie eine Optimierung in Betracht. rds_aurora.limitless_distributed_deadlock_timeout
AuroraLimitless: Ereignis DistributedDeadlockAbort abwarten
Der Prozess kommuniziert mit einem anderen Knoten, um eine Sitzung abzubrechen, die als Opfer in einem verteilten Deadlock ausgewählt wurde.
Ursachen
Anwendungsmuster führen zu verteilten Deadlocks.
Aktion
Untersuchen Sie Anwendungsmuster, die zu verteilten Deadlocks führen.
AuroraLimitless: Ereignis GatherRemoteStats abwarten
Der Prozess sammelt Statistiken von anderen Knoten im Cluster.
Ursachen
Überwachungs- oder Aktivitätsabfragen und -ansichten, z. B.limitless_stat_activity
, rufen Statistiken von anderen Knoten ab.
Aktion
Es sind keine weiteren Maßnahmen erforderlich.
AuroraLimitless: Ereignis GlobalSequenceRefresh abwarten
Der Prozess generiert einen neuen Sequenzwert und muss einen neuen Chunk aus der globalen Sequenz anfordern.
Ursachen
Eine hohe Rate der Generierung von Sequenzwerten kann in diesem Fall zu Verzögerungen führen, wenn sie nicht rds_aurora.limitless_sequence_chunk_size
ausreicht.
Aktion
Dies ist ein normales Ereignis. Wenn Sie feststellen, dass dieses Ereignis zu lange dauert, sollten Sie eine Optimierung in Betracht ziehenrds_aurora.limitless_sequence_chunk_size
. Weitere Informationen finden Sie in der Dokumentation zu Sequenzen in Limitless Database.
AuroraLimitless: Ereignis GlobalVacuumTimeExchange abwarten
Der Prozess tauscht Snapshot-Daten aus, um Vacuum zu unterstützen.
Ursachen
Knoten in Limitless Database tauschen die ältesten aktiven Snapshot-Daten mit anderen Knoten aus, um den korrekten Cutoff-Zeitpunkt für die Ausführung von Vacuum zu berechnen.
Aktion
Es sind keine weiteren Maßnahmen erforderlich.
AuroraLimitless: Ereignis DistributedTransactionMonitorGather abwarten
Der Prozess sammelt Transaktionsmetadaten von anderen Knoten, um die verteilte Transaktionsbereinigung zu unterstützen.
Ursachen
Knoten in Limitless Database tauschen Transaktionsmetadaten mit anderen Knoten aus, um festzustellen, wann der Status verteilter Transaktionen gelöscht werden kann.
Aktion
Es sind keine weiteren Maßnahmen erforderlich.
AuroraLimitlessActivity: Ereignis AdminTaskSchedulerMain abwarten
Wartet in der Hauptschleife des Taskplaner-Prozesses.
AuroraLimitlessActivity: Ereignis AdminTaskExecutorMain abwarten
Wartet in der Hauptschleife des Task-Executor-Prozesses.
AuroraLimitlessActivity: Ereignis AdminTaskMonitorMain abwarten
Wartet in der Hauptschleife des Task-Monitor-Prozesses.
AuroraLimitlessActivity: Ereignis DatabaseCleanupMonitorMain abwarten
Wartet in der Hauptschleife des Monitorprozesses zur Datenbankbereinigung.
AuroraLimitlessActivity: Ereignis TopologyCleanupMonitorMain abwarten
Wartet in der Hauptschleife des Monitorprozesses zur Topologiebereinigung.
AuroraLimitlessActivity: Ereignis ToplogyChangeMonitorMain abwarten
Wartet in der Hauptschleife des Prozesses zur Überwachung der Topologieänderung.
AuroraLimitlessActivity: Ereignis DistributedTransactionMonitorMain abwarten
Wartet in der Hauptschleife des verteilten Transaktionsüberwachungsprozesses.
AuroraLimitlessActivity: Ereignis GlobalVacuumMonitorMain abwarten
Wartet in der Hauptschleife des globalen Vakuumüberwachungsprozesses.