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.

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:

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.

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.

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:

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.

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.

Postmaster-Prozess

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

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: