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.

Schnelle Diagnose-Checkliste

Gehen Sie bei der ersten Untersuchung eines Leistungsproblems wie folgt vor:

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

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 entfernen.

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 Unterlimitmax_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:BgWorkerStartupIPC: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 festlegenmax_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 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

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

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:

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 Aurora PostgreSQL.

Ähnliche Informationen