LWLock:BufferIO (IPC:BufferIO) - Amazon Relational Database Service
Relevante Engine-VersionenKontextUrsachenAktionen

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 auf, wenn RDS für PostgreSQL darauf wartet, dass andere Prozesse ihre Eingabe-/Ausgabe-(I/O)-Vorgänge beenden, wenn sie gleichzeitig versuchen, 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 RDS für PostgreSQL relevant. Für Aurora PostgreSQL 12 und frühere Versionen wird dieses Warteereignis als lwlock:buffer_io bezeichnet, während es in der Version RDS für PostgreSQL 13 den Namen lwlock:bufferio trägt. Aus der Version RDS für 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 E/A: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

  • Checkpoints, die zu häufig auftreten oder zu viele geänderte Seiten leeren müssen

  • 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 Amazon CloudWatch-Metriken auf Korrelation zwischen starken Abnahmen der BufferCacheHitRatio- und LWLock:BufferIO-Warteereignisse. 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.

  • Stimmen Sie max_wal_size und checkpoint_timeout basierend auf der Spitzenzeit Ihrer Workload ab, wenn Sie sehen, dass LWLock:BufferIO mit Einbrüchen der Metrik BufferCacheHitRatio zusammenfällt. Identifizieren Sie dann, welche Abfrage sie möglicherweise verursachen könnte.

  • Ü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