

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.

# Verwalten temporärer Dateien mit PostgreSQL
<a name="PostgreSQL.ManagingTempFiles"></a>

In PostgreSQL kann eine komplexe Abfrage möglicherweise mehrere Sortier- und Hash-Vorgänge gleichzeitig durchführen, wobei jeder Vorgang Instance-Speicher verwendet, um Ergebnisse bis zu dem im [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) angegebenen Wert zu speichern. Wenn der Instance-Speicher nicht ausreicht, werden temporäre Dateien erstellt, um die Ergebnisse zu speichern. Diese werden auf die Festplatte geschrieben, um die Abfrageausführung abzuschließen. Später werden diese Dateien automatisch entfernt, nachdem die Abfrage abgeschlossen ist. In RDS für PostgreSQL werden diese Dateien in Amazon EBS auf dem Datenvolume gespeichert. Weitere Informationen finden Sie unter [Amazon-RDS-DB-Instance Speicher](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Sie können die in veröffentlichte `FreeStorageSpace` Metrik überwachen CloudWatch , um sicherzustellen, dass Ihre DB-Instance über ausreichend freien Speicherplatz verfügt. Weitere Informationen finden Sie unter [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm).

Wir empfehlen die Verwendung von Instances für Amazon-RDS-optimierte Lesevorgänge für Workloads mit mehreren gleichzeitigen Abfragen, die mehr temporäre Dateien nutzen. Diese  verwenden lokalen, auf Non-Volatile Memory Express (NVMe) basierenden Solid-State-Drive-Speicher (SSD) auf Blockebene, um die temporären Dateien zu platzieren. Weitere Informationen finden Sie unter [Verbesserung der Abfrageleistung für RDS für PostgreSQL mit Amazon-RDS-optimierten Lesevorgängen](USER_PostgreSQL.optimizedreads.md).

Sie können die folgenden Parameter und Funktionen verwenden, um die temporären Dateien in Ihrer Instance zu verwalten.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – Dieser Parameter bricht jede Abfrage ab, die die Größe von temp\$1files in KB überschreitet. Dieses Limit verhindert, dass Abfragen endlos ausgeführt werden und Speicherplatz mit temporären Dateien belegen. Sie können den Wert anhand der Ergebnisse des Parameters `log_temp_files` schätzen. Es hat sich bewährt, das Workload-Verhalten zu untersuchen und das Limit der Schätzung entsprechend festzulegen. Das folgende Beispiel zeigt, wie eine Abfrage abgebrochen wird, wenn sie das Limit überschreitet.

  ```
  postgres=>select * from pgbench_accounts, pg_class, big_table;
  ```

  ```
  ERROR: temporary file size exceeds temp_file_limit (64kB)
  ```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – Dieser Parameter sendet Nachrichten an die Datei postgresql.log, wenn die temporären Dateien einer Sitzung entfernt werden. Dieser Parameter erstellt Protokolle, nachdem eine Abfrage erfolgreich abgeschlossen wurde. Daher ist er bei der Fehlerbehebung aktiver, lang andauernder Abfragen möglicherweise nicht hilfreich. 

  Das folgende Beispiel zeigt, dass nach erfolgreichem Abschluss der Abfrage die Einträge in der Datei postgresql.log protokolliert werden, während die temporären Dateien bereinigt werden.

  ```
                      
  2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
  2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT:  select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
  2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
  2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT:  select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
  ```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – Diese Funktion, die von RDS für PostgreSQL 13 und höher verfügbar ist, bietet Einblick in die aktuelle Nutzung temporärer Dateien. Die abgeschlossene Abfrage erscheint nicht in den Ergebnissen der Funktion. Im folgenden Beispiel können Sie sich die Ergebnisse dieser Funktion ansehen.

  ```
  postgres=>select * from pg_ls_tmpdir();
  ```

  ```
        name       |    size    |      modification
  -----------------+------------+------------------------
   pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
   pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
   pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
   pgsql_tmp8351.1 |  703168512 | 2023-02-06 22:54:56+00
   pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
   pgsql_tmp8328.1 |  835031040 | 2023-02-06 22:54:56+00
   pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
  (7 rows)
  ```

  ```
  postgres=>select query from pg_stat_activity where pid = 8355;
                  
  query
  ----------------------------------------------------------------------------------------
  select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
  (1 row)
  ```

  Der Dateiname enthält die Verarbeitungs-ID (PID) der Sitzung, die die temporäre Datei generiert hat. Eine komplexere Abfrage, wie im folgenden Beispiel, führt eine Summenberechnung der temporären Dateien für jede PID durch.

  ```
  postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
  ```

  ```
   pid  | count |   sum
  ------+-------------------
   8355 |     2 | 2144501760
   8351 |     2 | 2090770432
   8327 |     1 | 1072250880
   8328 |     2 | 2144501760
  (4 rows)
  ```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – Wenn Sie den Parameter pg\$1stat\$1statements aktivieren, können Sie die durchschnittliche Nutzung temporärer Dateien pro Aufruf einsehen. Sie können die query\$1id der Abfrage identifizieren und verwenden, um die Nutzung temporärer Dateien zu untersuchen, wie im folgenden Beispiel gezeigt.

  ```
  postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
  ```

  ```
         queryid
  ----------------------
   -7170349228837045701
  (1 row)
  ```

  ```
  postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
  ```

  ```
         queryid        |          substr           | calls | temp_blks_read_per_call | temp_blks_written_per_call
  ----------------------+---------------------------+-------+-------------------------+----------------------------
   -7170349228837045701 | select a.aid from pgbench |    50 |                  239226 |                     388678
  (1 row)
  ```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** – Im Performance-Insights-Dashboard können Sie die Nutzung temporärer Dateien einsehen, indem Sie die Metriken **temp\$1bytes** und **temp\$1files** aktivieren. Anschließend können Sie den Durchschnitt dieser beiden Metriken sehen und feststellen, wie sie dem Abfrage-Workload entsprechen. In der Ansicht in Performance Insights werden nicht speziell die Abfragen angezeigt, die die temporären Dateien generieren. Wenn Sie jedoch Performance Insights mit der für `pg_ls_tmpdir` angezeigten Abfrage kombinieren, können Sie Fehler in Ihrem Abfrage-Workload beheben, analysieren und die Änderungen ermitteln. 

  Weitere Informationen zur Analyse von Metriken und Abfragen mit Performance Insights finden Sie unter [Analyse der Metriken mit dem Performance-Insights-Dashboard](USER_PerfInsights.UsingDashboard.md).

  Ein Beispiel für die Anzeige der Nutzung temporärer Dateien mit Performance Insights finden Sie unter [Anzeigen der Nutzung temporärer Dateien mit Performance Insights](PostgreSQL.ManagingTempFiles.Example.md).

# Anzeigen der Nutzung temporärer Dateien mit Performance Insights
<a name="PostgreSQL.ManagingTempFiles.Example"></a>

Sie können Performance Insights verwenden, um die Nutzung temporärer Dateien anzuzeigen, indem Sie die Metriken **temp\$1bytes** und **temp\$1files** aktivieren. Die Ansicht in Performance Insights zeigt nicht die spezifischen Abfragen an, die temporäre Dateien generieren. Wenn Sie jedoch Performance Insights mit der für `pg_ls_tmpdir` angezeigten Abfrage kombinieren, können Sie Fehler beheben, analysieren und die Änderungen in Ihrem Abfrage-Workload ermitteln.

1. Wählen Sie im Performance-Insights-Dashboard **Metriken verwalten** aus.

1. Wählen Sie **Datenbankmetriken** und die Metriken **temp\$1bytes** und **temp\$1files** aus, wie im folgenden Screenshot gezeigt.  
![\[Im Diagramm dargestellte Metriken.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)

1. Wählen Sie auf der Registerkarte **Top SQL** das Symbol **Einstellungen** aus.

1. Schalten Sie im Fenster **Einstellungen** die folgenden Statistiken ein, damit sie auf der Registerkarte **Top SQL** angezeigt werden, und wählen Sie **Weiter** aus.
   + Temporäre Schreibvorgänge pro Sekunde
   + Temporäre Lesevorgänge pro Sekunde
   + Temporäre Massenschreibvorgänge/Aufruf
   + Temporäre Massenlesevorgänge/Aufruf

1. Die temporäre Datei wird aufgegliedert, wenn sie mit der für `pg_ls_tmpdir` gezeigten Abfrage kombiniert wird, wie im folgenden Beispiel gezeigt.  
![\[Abfrage, die die Nutzung temporärer Dateien anzeigt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)

Die `IO:BufFileRead`- und `IO:BufFileWrite`-Ereignisse treten auf, wenn die häufigsten Abfragen in Ihrem Workload häufig temporäre Dateien erstellen. Mit Performance Insights können Sie die häufigsten Abfragen identifizieren, die auf `IO:BufFileRead` und `IO:BufFileWrite` warten, indem Sie die Abschnitte Durchschnittliche aktive Vorträge (AAS) in Datenbanklast und Top SQL überprüfen. 

![\[IO: BufFileRead und IO: BufFileWrite in der Grafik.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)


Weitere Informationen zur Analyse von Top-Abfragen und Last nach Warteereignis mit Performance Insights finden Sie unter [Überblick über die Registerkarte „Top SQL“](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Sie sollten die Abfragen identifizieren und optimieren, die zu einer erhöhten Nutzung temporärer Dateien und damit verbundenen Warteereignissen führen. Weitere Informationen zu diesen Warteereignissen und deren Behebung finden Sie unter [IO: BufFileRead und IO: BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html) .

**Anmerkung**  
Der Parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) steuert, wann der Sortiervorgang nicht mehr genügend Speicherplatz hat und die Ergebnisse in temporäre Dateien geschrieben werden. Wir empfehlen, die Einstellung dieses Parameters nicht höher als auf den Standardwert festzulegen, da dadurch jede Datenbanksitzung mehr Speicher belegen würde. Außerdem kann eine einzelne Sitzung, die komplexe Verknüpfungen und Sortierungen durchführt, parallele Operationen ausführen, bei denen jeder Vorgang Speicherplatz belegt.   
Wenn Sie einen umfangreichen Bericht mit mehreren Verknüpfungen und Sortierungen haben, empfiehlt es sich, diesen Parameter mit dem Befehl `SET work_mem` auf Sitzungsebene festzulegen. Dann wird die Änderung nur auf die aktuelle Sitzung angewendet und der Wert nicht global geändert.