Grundlegende Konzepte für Aurora PostgreSQL-Optimierung

Bevor Sie Ihre Aurora PostgreSQL-Datenbank optimieren, sollten Sie wissen, was Warteereignisse sind und warum sie auftreten. Sehen Sie sich auch die grundlegende Speicher- und Festplattenarchitektur von Aurora PostgreSQL an. Ein hilfreiches Architekturdiagramm finden Sie im PostgreSQL-Wikibook.

Aurora PostgreSQL-Warteereignisse

Ein Warteereignis zeigt eine Ressource an, auf die eine Sitzung wartet. Das Warteereignis Client:ClientRead tritt beispielsweise ein, wenn Aurora PostgreSQL darauf wartet, Daten von der client.emory- und Festplattenarchitektur von Aurora PostgreSQL zu empfangen. Zu den typischen Ressourcen, auf die eine Sitzung wartet, gehören die folgenden:

• Singlethread-Zugriff auf einen Puffer, beispielsweise wenn eine Sitzung versucht, einen Puffer zu ändern

• Eine Zeile, die derzeit von einer anderen Sitzung gesperrt ist

• Eine gelesene Datendatei

• Eine geschriebene Protokolldatei

Um beispielsweise eine Abfrage zu erfüllen, kann die Sitzung einen vollständigen Tabellenscan durchführen. Wenn sich die Daten noch nicht im Arbeitsspeicher befinden, wartet die Sitzung, bis die Datenträger-I/O abgeschlossen ist. Wenn die Puffer in den Speicher gelesen werden, muss die Sitzung möglicherweise warten, da andere Sitzungen auf dieselben Puffer zugreifen. Die Datenbank zeichnet die Wartezeiten unter Verwendung eines vordefinierten Warteereignisses auf. Diese Ereignisse sind in Kategorien eingeteilt.

Ein Wait-Ereignis allein zeigt kein Leistungsproblem an. Wenn sich beispielsweise die angeforderten Daten nicht im Speicher befinden, müssen die Daten von der Festplatte gelesen werden. Wenn eine Sitzung eine Zeile für eine Aktualisierung sperrt, wartet eine andere Sitzung darauf, dass die Zeile entsperrt wird, damit sie sie aktualisieren kann. Bei einem Commit muss gewartet werden, bis der Schreibvorgang in eine Protokolldatei abgeschlossen ist. Wartezeiten sind ein wesentlicher Bestandteil des normalen Funktionierens einer Datenbank.

Eine große Anzahl von Warteereignissen weist normalerweise auf ein Leistungsproblem hin. In solchen Fällen können Sie Warteereignisdaten verwenden, um zu bestimmen, wo die Sitzungen Zeit verbringen. Wenn beispielsweise ein Bericht, der normalerweise in Minuten ausgeführt wird, jetzt stundenlang ausgeführt wird, können Sie die Warteereignisse identifizieren, die am meisten zur Gesamtwartezeit beitragen. Wenn Sie die Ursachen für die häufigsten Warteereignisse ermitteln können, können Sie manchmal Änderungen vornehmen, die die Leistung verbessern. Wenn Ihre Sitzung beispielsweise auf eine Zeile wartet, die von einer anderen Sitzung gesperrt wurde, können Sie die Sperrsitzung beenden.

Aurora PostgreSQL-Speicher

Aurora PostgreSQL-Speicher ist in freigegeben und lokal unterteilt.

Themen

• Gemeinsamer Speicher in Aurora PostgreSQL
• Lokaler Speicher in Aurora PostgreSQL

Gemeinsamer Speicher in Aurora PostgreSQL

Aurora PostgreSQL weist beim Start der Instance gemeinsam genutzten Speicher zu. Shared Memory ist in mehrere Teilbereiche unterteilt. Nachfolgend finden Sie eine Beschreibung der wichtigsten.

Themen

• Freigegebene Puffer
• Write-Ahead-Protokoll (WAL)-Puffer

Freigegebene Puffer

Der freigegebene Pufferpool ist ein Aurora PostgreSQL-Speicherbereich, der alle Seiten enthält, die von Anwendungsverbindungen verwendet werden oder verwendet wurden. Eine Seite ist die Speicherversion eines Plattenblocks. Der gemeinsam genutzte Pufferpool zwischenspeichert die von der Platte gelesenen Datenblöcke. Der Pool reduziert die Notwendigkeit, Daten erneut von der Festplatte zu lesen, wodurch die Datenbank effizienter arbeitet.

Jede Tabelle und jeder Index wird als Array von Seiten einer festen Größe gespeichert. Jeder Block enthält mehrere Tupel, die Zeilen entsprechen. Ein Tupel kann auf jeglicher Seite gespeichert werden.

Der gemeinsam genutzte Pufferpool hat endlichen Speicher. Wenn eine neue Anforderung eine Seite erfordert, die sich nicht im Speicher befindet und kein Speicher mehr vorhanden ist, entfernt Aurora PostgreSQL eine weniger häufig verwendete Seite, um die Anforderung aufzunehmen. Die Räumungsrichtlinie wird durch einen Takt-Sweep-Algorithmus implementiert.

Der Parameter shared_buffers bestimmt, wie viel Speicher der Server für das Caching von Daten bereitstellt.

Write-Ahead-Protokoll (WAL)-Puffer

Ein Write-Ahead-Protokoll(WAL)-Puffer enthält Transaktionsdaten, die Aurora PostgreSQL später in den persistenten Speicher schreibt. Mithilfe des WAL-Mechanismus kann Aurora PostgreSQL Folgendes tun:

• Daten nach einem Fehler wiederherstellen

• Reduzieren Sie die Festplatten–I/O indem Sie häufige Schreibvorgänge auf die Festplatte vermeiden

Wenn ein Client Daten ändert, schreibt Aurora PostgreSQL die Änderungen in den WAL-Puffer. Wenn der Client einen COMMIT ausgibt, schreibt der WAL-Writerprozess Transaktionsdaten in die WAL-Datei.

Der Parameter wal_level bestimmt, wie viele Informationen in das WAL geschrieben werden.

Lokaler Speicher in Aurora PostgreSQL

Jeder Backend-Prozess weist lokalen Speicher für die Abfrageverarbeitung zu.

Themen

• Arbeitsspeicherbereich
• Wartungs-Arbeitsspeicherbereich
• Temporärer Pufferbereich

Arbeitsspeicherbereich

Der Arbeitsspeicherbereich enthält temporäre Daten für Abfragen, die Sortierungen und Hashes durchführen. Beispielsweise führt eine Abfrage mit einer ORDER BY-Klausel eine Sortierung durch. Abfragen verwenden Hash-Tabellen in Hash-Joins und Aggregationen.

Der work_mem-Parameter die Speichermenge, die von internen Sortiervorgängen und Hash-Tabellen verwendet werden soll, bevor in temporäre Plattendateien geschrieben wird. Der Standardwert lautet 4 MB. Mehrere Sitzungen können gleichzeitig ausgeführt werden, und jede Sitzung kann Wartungsvorgänge parallel ausführen. Aus diesem Grund kann der gesamte verwendete Arbeitsspeicher ein Vielfaches der Einstellung work_mem betragen.

Wartungs-Arbeitsspeicherbereich

Der Wartungsarbeitsspeicherbereich speichert Daten für Wartungsvorgänge zwischen. Zu diesen Vorgängen gehören das Vakuumieren, das Erstellen eines Index und das Hinzufügen von Fremdschlüsseln.

Der Parameter maintenance_work_mem gibt die maximale Speichermenge an, die von Wartungsvorgängen verwendet werden soll. Der Standardwert lautet 64 MB. In einer Datenbanksitzung kann jeweils nur ein Wartungsvorgang ausgeführt werden.

Temporärer Pufferbereich

Der temporäre Pufferbereich speichert temporäre Tabellen für jede Datenbanksitzung zwischen.

Jede Sitzung weist temporäre Puffer nach Bedarf bis zu dem von Ihnen angegebenen Limit zu. Wenn die Sitzung endet, löscht der Server die Puffer.

Der Parameter temp_buffers legt die maximale Anzahl temporärer Puffer fest, die von jeder Sitzung verwendet werden. Vor der ersten Verwendung temporärer Tabellen innerhalb einer Sitzung können Sie den temp_buffers-Wert ändern.

Aurora PostgreSQL-Prozesse

Aurora PostgreSQL verwendet mehrere Prozesse.

Themen

• Postmaster-Prozess
• Backend-Prozesse
• Hintergrundprozesse

Postmaster-Prozess

Der Postmaster-Prozess ist der erste Prozess, der beim Starten von Aurora PostgreSQL gestartet wird. Der Postmaster-Prozess hat die folgenden Hauptaufgaben:

• Hintergrundprozesse teilen und überwachen

• Empfangen Sie Authentifizierungsanfragen von Clientprozessen und authentifizieren Sie sie, bevor Sie der Datenbank erlauben, Anfragen zu bearbeiten

Backend-Prozesse

Wenn der Postmaster eine Client-Anfrage authentifiziert, forkisiert der Postmaster einen neuen Backend-Prozess, auch Postgres-Prozess genannt. Ein Client-Prozess verbindet sich mit genau einem Backend-Prozess. Der Client-Prozess und der Backend-Prozess kommunizieren direkt ohne Eingriff des Postmaster-Prozesses.

Hintergrundprozesse

Der Postmaster-Prozess teilt mehrere Prozesse, die unterschiedliche Backend-Aufgaben ausführen. Einige der wichtigeren sind die folgenden:

• WAL-Writer

  Aurora PostgreSQL schreibt Daten im WAL-Puffer (Write Ahead Logging) in die Protokolldateien. Das Prinzip der Write-Ahead-Protokollierung besteht darin, dass die Datenbank keine Änderungen in die Datendateien schreiben kann, bis die Datenbank Protokolldatensätze geschrieben hat, die diese Änderungen auf die Festplatte beschreiben. Der WAL-Mechanismus reduziert Festplatten-I/O und ermöglicht Aurora PostgreSQL, die Protokolle zu verwenden, um die Datenbank nach einem Fehler wiederherzustellen.

• Hintergrund-Autor

  Dieser Prozess schreibt regelmäßig schmutzige (modifizierte) Seiten aus den Speicherpuffern in die Datendateien. Eine Seite wird schmutzig, wenn ein Backend-Prozess sie im Speicher ändert.

• Autovacuum-Daemon

  Der Daemon besteht aus Folgendem:

  • Der Autovacuum-Launcher

  • Die Autovacuum-Worker-Prozesse

  Wenn Autovacuum aktiviert ist, sucht es nach Tabellen mit einer großen Anzahl eingefügter, aktualisierter oder gelöschter Tupel. Der Daemon hat folgende Aufgaben:

  • Wiederherstellen oder Wiederverwenden von Speicherplatz, der von aktualisierten oder gelöschten Zeilen belegt ist

  • Vom Planer verwendete Statistiken aktualisieren

  • Schutz vor Verlust alter Daten durch Transaktions-ID-Wraparound

  Die Autovacuum-Funktion automatisiert die Ausführung von VACUUM- und ANALYZE-Befehlen. VACUUM hat folgende Varianten: Standard und Voll. Standardvakuum läuft parallel zu anderen Datenbankvorgängen. VACUUM FULL erfordert eine exklusive Sperre für die Tabelle, an der es arbeitet. Daher kann es nicht parallel zu Vorgänge ausgeführt werden, die auf dieselbe Tabelle zugreifen. VACUUM erzeugt eine beträchtliche Menge an I/O-Datenverkehr, was zu einer schlechten Leistung anderer aktiver Sitzungen führen kann.