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.
# Erste Fehlerbehebung für häufig auftretende PostgreSQL-Leistungsprobleme in
In diesem Handbuch werden die vier häufigsten Leistungsprobleme behandelt, die betreffen: Aufblähung von Tabellen und Indizes, Erschöpfung der Ressourcen bei parallel Abfragen, hoher Verbindungs- und Authentifizierungsdruck sowie Autovacuum-Tuning. Verwenden Sie dieses Handbuch als Checkliste für die Erstdiagnose, wenn Sie Leistungseinbußen feststellen, bevor Sie mit eingehenderen Untersuchungen beginnen.
In jedem Abschnitt werden die Symptome beschrieben, die Sie möglicherweise beobachten, und es werden Diagnosefragen zur Bestätigung der Grundursache bereitgestellt, und es werden spezifische Schritte zur Behebung empfohlen.
**Leistungsrückgänge verstehen, bei denen sich nichts geändert hat**
PostgreSQL-Workloads laufen oft wochen- oder monatelang ohne Probleme und erleben dann plötzliche Leistungseinbußen, obwohl der Anwendungscode und die Abfragemuster unverändert erscheinen. Das liegt daran, dass die Datenbankumgebung nie wirklich statisch ist — mehrere unsichtbare Faktoren verändern sich im Laufe der Zeit und können Planänderungen oder Ressourcenkonflikte auslösen:
**Die Akkumulation von Blähungen ist eine Änderung der Arbeitslast.** Die Multiversion Concurrency Control (MVCC) von PostgreSQL behält alte Zeilenversionen bei, bis Autovacuum sie zurückfordert. Wenn sich tote Tupel schneller ansammeln, als Autovacuum sie verarbeiten kann, werden Tabellen und Indizes physisch größer. Der Abfrageplaner wechselt dann möglicherweise von effizienten Indexscans zu sequentiellen Scans, da sich die Kostenschätzungen mit zunehmender Tabellengröße ändern. Ihr SQL hat sich nicht geändert, wohl aber die Daten, die der Planer sieht.
**Neue Parameterwerte bedeuten eine Änderung der Arbeitslast.** Eine parametrisierte Abfrage, die für einen Wertebereich eine gute Leistung erbringt, kann schlecht abschneiden, wenn die Anwendung anfängt, einen anderen Bereich zu verwenden. PostgreSQL kann einen generischen Ausführungsplan wiederverwenden, der Datenverzerrungen im neuen Bereich nicht berücksichtigt, oder die Statistiken des Planers geben die Verteilung dieser Werte möglicherweise nicht genau wieder. Wenn auch Blähungen auftreten, verschärfen sich die Auswirkungen — ein suboptimaler Plan scannt jetzt deutlich mehr tote Daten.
**Statistiken können auch dann veraltet sein, wenn das Autovakuumverfahren läuft.** Autovacuum-Auslöser `ANALYZE` basieren auf der Anzahl der eingefügten oder aktualisierten Zeilen und nicht darauf, ob sich die Datenverteilung erheblich geändert hat. Wenn Ihre Anwendung dazu übergeht, einen anderen Wertebereich oder ein anderes Zeitfenster abzufragen, sind die Kostenschätzungen des Planers möglicherweise ungenau, obwohl Autovacuum kürzlich ausgeführt wurde.
**Das allgemeine Datenbankwachstum ist eine Änderung der Arbeitslast.** Wenn die Tabellen im Laufe der Zeit wachsen, nimmt auch das Volumen der Datenseiten zu, die Abfragen scannen müssen. Abfragen, die bei kleineren Tabellen eine gute Leistung erbrachten, können mit zunehmender Tabellengröße zu Latenz führen, selbst wenn die Abfragelogik und die Indizes unverändert bleiben. Überwachen Sie , um Trends beim Speicherwachstum zu verfolgen.
Wenn Sie Performance-Regressionen untersuchen, bei denen sich „nichts geändert hat“, sollten Sie die Anhäufung von Blähungen, neue Wertebereiche für Parameter, das allgemeine Datenbankwachstum und veraltete Statistiken als wahrscheinlichste Hauptursachen betrachten. Verwenden Sie die Diagnoseschritte in diesem Handbuch, um zu überprüfen, welcher Faktor zutrifft.
Weitere Informationen finden Sie hier:
[Wartungsaktivitäten für PostgreSQL-Datenbanken in Amazon RDS und Amazon Aurora](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/introduction.html) (AWS Prescriptive Guidance)
[Optimierung der PostgreSQL-Abfrageleistung](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-query-tuning/introduction.html) (AWS Prescriptive Guidance)
[Optimieren von PostgreSQL-Parametern in Amazon RDS und Amazon Aurora](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/introduction.html)
[Amazon RDS-Metriken auf Instanzebene](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html#rds-cw-metrics-instance) (Überwachung von `FreeStorageSpace` Speicherwachstumstrends)
## Schnelle Diagnose-Checkliste
Gehen Sie bei der ersten Untersuchung eines Leistungsproblems wie folgt vor:
1. **Prüfen Sie`pg_stat_activity`.** Sehen Sie sich die Anzahl der Verbindungen, ungenutzte Transaktionssitzungen und lang andauernde Abfragen an. Weitere Informationen finden Sie unter [Grundlegende Konzepte für RDS für das PostgreSQL-Tuning](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Tuning.concepts.html).
1. **Suchen Sie nach Blähungen.** Achten Sie auf hohe Werte `pg_stat_user_tables` und ziehen Sie die Verwendung `pgstattuple` für präzise Messungen `n_dead_tup` in Betracht. Weitere Informationen finden Sie unter Aufblähung von [aus Tabellen entfernen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pg_repack.html) mit pg\_repack.
1. **Prüfen Sie. `pg_stat_user_tables`** Suchen Sie nach hohen `n_dead_tup` Werten und veralteten `last_autovacuum` Zeitstempeln. Weitere Informationen finden Sie unter [Arbeiten mit PostgreSQL-Autovacuum auf Amazon RDS Arbeiten mit PostgreSQL-Autovacuum](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) .
1. **Überblick `EXPLAIN ANALYZE` über langsame Abfragen.** Suchen Sie bei großen Tabellen nach parallel Plänen und sequentiellen Scans. Weitere Informationen finden Sie unter [Bewährte Methoden für parallel Abfragen in RDS for](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ParallelQueries.html) PostgreSQL.
1. **Check CloudWatch - und Performance Insights Insights-Metriken.** Überprüfen Sie die CPU-Auslastung, die Anzahl der Verbindungen, die IOPS und den freien Speicherplatz. Weitere Informationen finden Sie unter [Überwachung von Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MonitoringOverview.html). Allgemeine Warteereignisse und Abhilfemaßnahmen finden Sie unter .
1. **Überprüfen Sie Ihre DB-Parametergruppe.** Überprüfen `max_parallel_workers_per_gather` und automatische Vakuumierung der Einstellungen. Weitere Informationen finden Sie unter [Optimieren von PostgreSQL-Parametern in Amazon RDS und Amazon Aurora](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/introduction.html).
## Aufblähung von Tabellen und Indizes
Ein Aufblähen von Tabellen und Indizes tritt auf, wenn sich tote Tupel schneller in Ihren Tabellen ansammeln, als sie durch Autovacuum-Verfahren zurückgewonnen werden können. Im Laufe der Zeit führt dies zu einer allmählichen Verschlechterung der Abfrageleistung, einer erhöhten Speichernutzung und suboptimalen Abfrageplänen.
### Symptome
+ Schrittweise Verschlechterung der Abfrageleistung über Wochen oder Monate
+ Steigende Speichernutzung trotz stabilem Datenvolumen
+ Aufgrund veralteter Statistiken zieht der Abfrageplaner sequentielle Scans Indexscans vor
+ Hoher Anteil an `dead_tuple_count` Tabellenstatistiken
### Diagnose
Sie können die Aufblähung aller Tabellen abschätzen, indem Sie den Systemkatalog abfragen. Für diesen Ansatz sind keine Erweiterungen erforderlich:
```
SELECT schemaname, relname,
n_dead_tup,
n_live_tup,
ROUND(n_dead_tup::numeric / GREATEST(n_live_tup, 1) * 100, 2) AS dead_pct,
last_autovacuum,
last_autoanalyze
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY n_dead_tup DESC
LIMIT 20;
```
Um der Überlastung entgegenzuwirken, können Sie die `pg_repack` Erweiterung verwenden, um Tabellen und Indizes mit minimaler Sperre neu zu organisieren. Weitere Informationen finden Sie unter [Bloat aus Tabellen mit pg\_repack entfernen Bloat aus Tabellen entfernen mit pg\_repack](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pg_repack.html) [entfernen](https://aws.amazon.com/blogs/database/remove-bloat-from-amazon-aurora-and-rds-for-postgresql-with-pg_repack/).
**Wichtig**
Anstatt sich auf manuelle Wartung zu verlassen, sollten Sie sicherstellen, dass Autovacuum aktiviert und richtig auf Ihre Arbeitslast abgestimmt ist. Empfehlungen [Autovakuum-Tuning](#PostgreSQL.InitialTroubleshooting.Autovacuum) zur Optimierung finden Sie unter.
## Erschöpfung der Ressourcen für parallele Abfragen
PostgreSQL kann Abfragen parallel ausführen, um die Leistung für große sequentielle Scans und Aggregationen zu verbessern. Jeder parallel Worker ist jedoch ein vollständiger Backend-Prozess, der auf `max_worker_processes` (und das Unterlimit`max_parallel_workers`) angerechnet und seinen eigenen zuweist. `work_mem` Eine einzelne Abfrage mit 4 parallel Workern kann Hunderte von Megabyte Arbeitsspeicher und viel CPU verbrauchen. Bei hoher Parallelität kann eine übermäßige Parallelität CPU und Arbeitsspeicher schnell erschöpfen.
Zu den häufigsten Symptomen gehören plötzliche CPU-Spitzen, hohe Speicherauslastung pro Abfrage und erhöhte Speicherauslastung ohne `DatabaseConnections` Anwendungsänderungen CloudWatch. Sie können auch Warteereignisse wie `IPC:BgWorkerStartup``IPC:ExecuteGather`, und `IPC:ParallelFinish` beobachten. Weitere Informationen zu diesen Warteereignissen finden Sie unter .
Deaktivieren Sie für die meisten OLTP- und Produktionsworkloads mit hoher Parallelität die automatische Parallelität, indem Sie sie in Ihrer DB-Parametergruppe festlegen`max_parallel_workers_per_gather = 0`. Anschließend können Sie die Parallelität für bestimmte Analyse- oder Berichtssitzungen selektiv aktivieren, indem Sie den Parameter pro Sitzung oder pro Rolle festlegen.
Eine ausführliche Anleitung zur Diagnose und Steuerung des Verhaltens parallel Abfragen finden Sie unter [Bewährte Methoden für parallel Abfragen in RDS for](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ParallelQueries.html) PostgreSQL.
## Hoher Verbindungs- und Authentifizierungsdruck
Verbindungsabwanderung — häufiges Öffnen und Schließen von Datenbankverbindungen ohne Pooling — verursacht einen Authentifizierungsaufwand und kann die verfügbaren Verbindungssteckplätze erschöpfen. Verbindungen im Leerlauf, die offen bleiben, verbrauchen ebenfalls Steckplätze, ohne dass sie nützliche Arbeit verrichten.
### Symptome
+ Erhöhte Performance `total_auth_attempts` Insights Insights-Überwachung. Weitere Informationen finden Sie unter .
+ Langsame Verbindungsaufbauzeiten
+ `FATAL: too many connections for role`oder `remaining connection slots are reserved` Fehler
+ CPU-Spitzen korrelierten mit der Verbindungsabwanderung
### Diagnose
Führen Sie die folgende Abfrage aus, um Ihren aktuellen Verbindungsstatus zu überprüfen:
```
SELECT
setting::int AS max_connections,
(SELECT count(*) FROM pg_stat_activity) AS current_connections,
(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle') AS idle_connections,
(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle in transaction') AS idle_in_txn
FROM pg_settings
WHERE name = 'max_connections';
```
Eine hohe Anzahl von `idle` `idle in transaction` Verbindungen im Verhältnis zu `max_connections` weist darauf hin, dass Verbindungen nicht ordnungsgemäß freigegeben werden. Idle-in-transaction Verbindungen sind besonders problematisch, da sie Sperren enthalten und verhindern, dass tote Tupel durch Autovakuumbetrieb zurückgewonnen werden.
### Abhilfe
+ **Stellen Sie Verbindungspooling bereit.** Verwenden Sie PgBouncer oder Amazon RDS Proxy, um die Anzahl der direkten Verbindungen zu Ihrer Datenbank zu reduzieren. Beim Verbindungspooling werden bestehende Verbindungen wiederverwendet, anstatt für jede Anfrage neue Verbindungen zu erstellen.
+ **Eingestellt. `idle_in_transaction_session_timeout`** Dieser Parameter beendet automatisch Sitzungen, die in einer Transaktion über die angegebene Dauer hinaus inaktiv bleiben. Dadurch wird verhindert, dass lang andauernde inaktive Transaktionen Sperren enthalten und Autovacuum blockieren.
+ **Überprüfen Sie die Verbindungsverarbeitung der Anwendung.** Stellen Sie sicher, dass Ihre Anwendung Verbindungen umgehend schließt und Transaktionen nicht länger als nötig offen hält.
**Anmerkung**
Parallele Query-Worker verbrauchen CPU und Arbeitsspeicher. Wenn Sie neben parallel Abfragen auch eine Ressourcenerschöpfung beobachten, finden Sie unter Hinweise [Erschöpfung der Ressourcen für parallele Abfragen](#PostgreSQL.InitialTroubleshooting.ParallelQuery) zur Steuerung der parallel Worker-Nutzung.
## Verwenden von Performance Insights Insights-Warteereignissen zur Fehlerbehebung
Performance Insights erfasst Warteereignisse, die zeigen, wo Ihre Datenbank Zeit verbringt. Bei der Untersuchung von Leistungsproblemen können Sie anhand von Warteereignissen feststellen, ob der Engpass auf CPU-, Sperren- I/O, Netzwerk- oder Prozesskommunikation zurückzuführen ist. Zu den häufigsten Kategorien von Warteereignissen, die bei den in diesem Handbuch beschriebenen Problemen auftreten, gehören:
+ **CPU** — Die Sitzung ist auf der CPU aktiv oder wartet auf eine CPU. Ereignisse mit hohen CPU-Wartezeiten korrelieren häufig mit übermäßiger Parallelität oder ineffizienten Abfrageplänen beim Scannen aufgeblähter Tabellen.
+ **IPC (Inter-Process Communication)** — Wartet auf Ereignisse wie `IPC:BgWorkerStartup``IPC:ExecuteGather`, und `IPC:ParallelFinish` weist auf einen Mehraufwand für die parallel Abfragekoordination hin.
+ **IO** — Warteereignisse, die z. B. `IO:DataFileRead` darauf hinweisen, dass Abfragen Daten aus dem Speicher lesen, weil sich die erforderlichen Seiten nicht im gemeinsamen Speicher befinden. Dies ist häufig der Fall, wenn aufgeblähte Tabellen den Puffercache überschreiten.
+ **Sperren** — Wartet auf Ereignisse wie `Lock:transactionid` und `Lock:tuple` deutet auf Konflikte zwischen Sitzungen hin. Idle-in-transaction Verbindungen können Sperren enthalten, die andere Abfragen blockieren und Autovacuum auslösen.
+ **Client** — Warteereignisse, die z. B. `Client:ClientRead` darauf hinweisen, dass die Datenbank darauf wartet, dass die Anwendung Daten sendet. Ereignisse mit hoher Client-Wartezeit können auf Verbindungsabwanderung oder Netzwerklatenz hinweisen.
Eine vollständige Referenz der Warteereignisse, die häufig auf Leistungsprobleme hinweisen, und deren empfohlene Abhilfemaßnahmen finden Sie unter .
## Autovakuum-Tuning
Autovacuum ist der Hintergrundprozess, der tote Tupel zurückgewinnt, eine Aufblähung von Tabellen und Indizes verhindert, Planer-Statistiken aktualisiert und vor Transaktions-ID-Wraparound schützt. Die standardmäßigen Autovacuum-Einstellungen sind konservativ und für kleine Datenbanken konzipiert. High-write Produktionsworkloads müssen fast immer optimiert werden.
Wenn Autovacuum mit Ihrem Schreib-Workload nicht Schritt halten kann, häufen sich Blähungen an, die Planer-Statistiken veralten und das Risiko, dass Transaktions-IDs umgekrempelt werden, steigt. Bei einer `age(relfrozenxid)` Annäherung an die Marke von 2 Milliarden wird die Datenbank heruntergefahren, um Datenbeschädigungen zu verhindern.
Ausführliche Anleitungen zur Optimierung der Autovacuum-Parameter, zur Überwachung der Vakuumaktivität und zur Konfiguration tabellenbezogener Overrides finden Sie unter Arbeiten mit PostgreSQL-Autovacuum [auf Amazon RDS PostgreSQL-Autovacuum auf](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) Aurora PostgreSQL.
## Ähnliche Informationen
+ [Bewährte Methoden für parallel Abfragen in RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ParallelQueries.html)
+ [Behandlung toter Verbindungen in PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.html)
+ [Arbeiten mit PostgreSQL Autovacuum auf Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
+ [Allgemeine DBA-Aufgaben für RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html)
+ [Arbeiten mit PostgreSQL Autovacuum auf Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
+ [Grundlegendes zum Autovacuum in Umgebungen mit Amazon RDS für PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/)