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:BufferIO (IPC:BufferIO)
Das LWLock:BufferIO Ereignis tritt ein, wenn Aurora PostgreSQL oder RDS for PostgreSQL darauf wartet, dass andere Prozesse input/output (I/O (ihre) Operationen beenden, während gleichzeitig versucht wird, auf eine Seite zuzugreifen. Sein Zweck besteht darin, dass dieselbe Seite in den freigegebenen Puffer eingelesen wird.
Relevante Engine-Versionen
Diese Warteereignisinformationen sind für alle Versionen von Aurora PostgreSQL. Für Aurora PostgreSQL 12 und frühere Versionen wird dieses Warteereignis als lwlock:buffer_io bezeichnet, während es in der Version Aurora PostgreSQL 13 den Namen lwlock:bufferio trägt. Aus der Version Aurora PostgreSQL 14 wurde das BufferIO-Warteereignis von LWLock zum Warteereignistyp IPC (ipc:bufferio) verschoben.
Kontext
Jeder gemeinsam genutzte Puffer hat eine I/O-Sperre, die mit dem LWLock:BufferIO-Warteereignis verbunden ist, jedes Mal, wenn ein Block (oder eine Seite) außerhalb des gemeinsam genutzten Pufferpools abgerufen werden muss.
Diese Sperre wird verwendet, um mehrere Sitzungen zu behandeln, die alle Zugriff auf denselben Block benötigen. Dieser Block muss von außerhalb des gemeinsam genutzten Pufferpools gelesen werden, der durch den shared_buffers-Parameter definiert wird.
Sobald die Seite innerhalb des Shared Buffer Pool gelesen wird, wird die LWLock:BufferIO-Sperre freigegeben.
Anmerkung
Das LWLock:BufferIO-Wait-Ereignis geht dem IO: DataFileRead-Warteereignis voraus. Das IO:DataFileRead-Wait-Ereignis tritt auf, während Daten aus dem Speicher gelesen werden.
Weitere Informationen zu leichten Sperren finden Sie unter Übersicht über Sperren
Ursachen
Häufige Gründe dafür, dass das LWLock:BufferIO-Ereignis in den Top-Wartezeiten angezeigt wird, sind die folgenden:
-
Mehrere Backends oder Verbindungen, die versuchen, auf dieselbe Seite zuzugreifen, für die auch ein I/O-Vorgang aussteht
-
Das Verhältnis zwischen der Größe des gemeinsam genutzten Pufferpools (definiert durch den
shared_buffers-Parameter) und der Anzahl der Puffer, die von der aktuellen Workload benötigt werden -
Die Größe des freigegebenen Pufferpools ist nicht gut mit der Anzahl der Seiten, die durch andere Vorgänge geräumt werden
-
Große oder aufgeblähte Indizes, bei denen die Engine mehr Seiten als nötig in den freigegebenen Pufferpool lesen muss
-
Mangel an Indizes, die die DB-Engine dazu zwingen, mehr Seiten aus den Tabellen als nötig zu lesen
-
Plötzliche Spitzen für Datenbankverbindungen, die versuchen, Vorgänge auf derselben Seite auszuführen
Aktionen
Abhängig von den Ursachen Ihres Wait-Ereignisses empfehlen wir verschiedene Aktionen:
-
Beobachten Sie die CloudWatch Amazon-Metriken, um die Korrelation zwischen starken Rückgängen der Ereignisse
BufferCacheHitRatioundLWLock:BufferIOWarteereignissen zu ermitteln. Dieser Effekt kann bedeuten, dass Sie eine kleine Einstellung für gemeinsame Puffer haben. Möglicherweise müssen Sie es erhöhen oder Ihre DB-Instance-Klasse hochskalieren. Sie können Ihre Workload in mehr Reader-Knoten aufteilen. -
Überprüfen Sie, ob Sie nicht verwendete Indizes haben, und entfernen Sie sie dann.
-
Verwenden Sie partitionierte Tabellen (die auch partitionierte Indizes haben). Dies hilft, die Neuordnung des Index niedrig zu halten und ihre Auswirkungen zu reduzieren.
-
Vermeiden Sie, Spalten unnötig zu indizieren.
-
Verhindern Sie plötzliche Spitzen der Datenbankverbindung, indem Sie einen Verbindungspool verwenden.
-
Beschränken Sie die maximale Anzahl von Verbindungen zur Datenbank als bewährte Methode
