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 die Optimierung von RDS für PostgreSQL Bevor Sie Ihre Datenbank von RDS für PostgreSQL optimieren, sollten Sie wissen, was Warteereignisse sind und warum sie auftreten. Sehen Sie sich auch die grundlegende Speicher- und Festplattenarchitektur von RDS für PostgreSQL an. Ein hilfreiches Architekturdiagramm finden Sie im [PostgreSQL](https://en.wikibooks.org/wiki/PostgreSQL/Architecture)-Wikibook. **Topics** + [Warteereignisse von RDS für PostgreSQL](PostgreSQL.Tuning.concepts.waits.md) + [Speicher von RDS für PostgreSQL](PostgreSQL.Tuning.concepts.memory.md) + [Prozesse von RDS für PostgreSQL](PostgreSQL.Tuning.concepts.processes.md) # Warteereignisse von RDS für PostgreSQL Ein *Warteereignis* ist ein Hinweis darauf, dass die Sitzung auf eine Ressource wartet. Das Warteereignis `Client:ClientRead` tritt beispielsweise auf, wenn RDS für PostgreSQL darauf wartet, Daten vom Client zu empfangen. Sitzungen warten in der Regel auf Ressourcen wie 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 einzelnes Warteereignis ist kein Anzeichen für ein Leistungsproblem. 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 hingegen 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 Stunden dauert, 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. # Speicher von RDS für PostgreSQL Der Arbeitsspeicher von RDS für PostgreSQL ist in gemeinsam genutztem und lokalem Speicher unterteilt. **Topics** + [Gemeinsam genutzter Arbeitsspeicher von RDS für PostgreSQL](#PostgreSQL.Tuning.concepts.shared) + [Lokaler Arbeitsspeicher in RDS für PostgreSQL](#PostgreSQL.Tuning.concepts.local) ## Gemeinsam genutzter Arbeitsspeicher von RDS für PostgreSQL RDS für PostgreSQL weist beim Start der Instance gemeinsam genutzten Speicher zu. Shared Memory ist in mehrere Teilbereiche unterteilt. Die folgenden Abschnitte enthalten Beschreibungen der wichtigsten Teilbereiche. **Topics** + [Freigegebene Puffer](#PostgreSQL.Tuning.concepts.buffer-pool) + [Write-Ahead-Protokoll (WAL)-Puffer](#PostgreSQL.Tuning.concepts.WAL) ### Freigegebene Puffer Der *freigegebene Pufferpool* ist ein Speicherbereich von RDS für PostgreSQL, der alle Seiten enthält, die von Anwendungsverbindungen verwendet werden oder 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 RDS für PostgreSQL eine weniger häufig verwendete Seite, um die Anforderung zu erfüllen. 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. Der Standardwert ist auf `{DBInstanceClassMemory/32768}` Byte festgelegt, basierend auf dem verfügbaren Speicher für die DB-Instance. ### Write-Ahead-Protokoll (WAL)-Puffer Ein *Write-Ahead-Protokoll-Puffer (WAL)* enthält Transaktionsdaten, die RDS für PostgreSQL später in den persistenten Speicher schreibt. Mithilfe des WAL-Mechanismus kann RDS für PostgreSQL folgende Vorgänge ausführen: + Daten nach einem Fehler wiederherstellen + Reduzieren Sie die I/O Festplattenkapazität, indem Sie häufige Schreibvorgänge auf die Festplatte vermeiden Wenn ein Client Daten ändert, schreibt RDS für 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. Mögliche Werte sind zum Beispiel `minimal`, `replica` und `logical`. ## Lokaler Arbeitsspeicher in RDS für PostgreSQL Jeder Backend-Prozess weist lokalen Speicher für die Abfrageverarbeitung zu. **Topics** + [Arbeitsspeicherbereich](#PostgreSQL.Tuning.concepts.local.work_mem) + [Wartungs-Arbeitsspeicherbereich](#PostgreSQL.Tuning.concepts.local.maintenance_work_mem) + [Temporärer Pufferbereich](#PostgreSQL.Tuning.concepts.temp) ### 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 Parameter `work_mem` für die Speichergröße, die von internen Sortiervorgängen und Hash-Tabellen belegt werden soll, bevor in temporäre Festplattendateien geschrieben wird, gemessen in Megabyte. 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 Speichergröße an, die von Wartungsvorgängen verwendet werden soll, gemessen in Megabyte. 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 der jeweiligen Sitzung verwendet werden, gemessen in Megabyte. Der Standardwert ist 8 MB. Vor der ersten Verwendung temporärer Tabellen innerhalb einer Sitzung können Sie den `temp_buffers`-Wert ändern. # Prozesse von RDS für PostgreSQL RDS für PostgreSQL verwendet mehrere Prozesse. **Topics** + [Postmaster-Prozess](#PostgreSQL.Tuning.concepts.postmaster) + [Backend-Prozesse](#PostgreSQL.Tuning.concepts.backend) + [Hintergrundprozesse](#PostgreSQL.Tuning.concepts.vacuum) ## Postmaster-Prozess Der *Postmaster-Prozess* ist der erste Prozess, der beim Öffnen von RDS für 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 RDS für 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ängen ausgeführt werden, die auf dieselbe Tabelle zugreifen. `VACUUM`erzeugt eine beträchtliche Menge an I/O Datenverkehr, was zu Leistungseinbußen bei anderen aktiven Sitzungen führen kann.