

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.

# Speicher von RDS für PostgreSQL
<a name="PostgreSQL.Tuning.concepts.memory"></a>

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
<a name="PostgreSQL.Tuning.concepts.shared"></a>

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
<a name="PostgreSQL.Tuning.concepts.buffer-pool"></a>

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
<a name="PostgreSQL.Tuning.concepts.WAL"></a>

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
<a name="PostgreSQL.Tuning.concepts.local"></a>

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
<a name="PostgreSQL.Tuning.concepts.local.work_mem"></a>

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
<a name="PostgreSQL.Tuning.concepts.local.maintenance_work_mem"></a>

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
<a name="PostgreSQL.Tuning.concepts.temp"></a>

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.