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.
IPC:parallel-Warteereignisse
Die folgenden IPC:parallel wait events weisen darauf hin, dass eine Sitzung auf die Interprozesskommunikation in Bezug auf parallele Abfrageausführungen wartet.
-
IPC:BgWorkerStartup– Ein Prozess wartet darauf, dass ein paralleler Worker-Prozess seine Startsequenz abgeschlossen hat. Dies geschieht, wenn Worker für eine parallele Abfrageausführung initialisiert werden. -
IPC:BgWorkerShutdown– Ein Prozess wartet darauf, dass ein paralleler Worker-Prozess seine Shutdown-Sequenz abgeschlossen hat. Dies geschieht während der Bereinigungsphase der parallelen Abfrageausführung. -
IPC:ExecuteGather– Ein Prozess wartet darauf, während der Abfrageausführung Daten von parallelen Worker-Prozessen zu empfangen. Dies ist der Fall, wenn der Leader-Prozess Ergebnisse von seinen Workern erfassen muss. -
IPC:ParallelFinish– Ein Prozess wartet darauf, dass parallele Worker ihre Ausführung beenden und ihre Endergebnisse melden. Dies geschieht während der Abschlussphase der parallelen Abfrageausführung.
Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
Kontext
Bei der parallelen Abfrageausführung in PostgreSQL arbeiten mehrere Prozesse zusammen, um eine einzelne Abfrage zu verarbeiten. Wenn festgestellt wird, dass eine Abfrage für die Parallelisierung geeignet ist, koordiniert ein Leader-Prozess die Arbeit mit einem oder mehreren parallelen Worker-Prozessen je nach max_parallel_workers_per_gather-Parametereinstellung. Der Leader-Prozess teilt die Arbeit auf die einzelnen Worker auf und jeder Worker verarbeitet unabhängig seinen Teil der Daten. Die Ergebnisse werden dann an den Leader-Prozess zurückgemeldet.
Anmerkung
Jeder parallele Worker fungiert als separater Prozess mit Ressourcenanforderungen, die einer vollständigen Benutzersitzung ähneln. Das bedeutet, dass eine parallele Abfrage mit 4 Workern bis zu fünfmal so viele Ressourcen (CPU, Arbeitsspeicher, I/O-Bandbreite) verbrauchen kann wie eine nicht parallele Abfrage, da sowohl der Leader-Prozess als auch die einzelnen Worker-Prozesse ihre eigenen Ressourcenzuweisungen verwalten. So werden beispielsweise Einstellungen wie work_mem individuell auf jeden Worker angewendet, wodurch sich die gesamte Speicherbelegung aller Prozesse vervielfachen kann.
Die Architektur einer parallelen Abfrage besteht aus drei Hauptkomponenten:
-
Leader-Prozess: Dies ist der Hauptprozess, der den Parallelbetrieb einleitet, den Workload aufteilt und die Abstimmung mit den Worker-Prozessen vornimmt.
-
Worker-Prozesse: Dies sind Hintergrundprozesse, die Teile der Abfrage parallel ausführen.
-
Gather/Gather merge: Dies sind Operationen, die Ergebnisse mehrerer Worker-Prozesse kombinieren und zurück an den Leader melden.
Während der parallelen Ausführung müssen Prozesse über Mechanismen der Interprozesskommunikation (IPC) miteinander kommunizieren. Diese IPC-Warteereignisse treten in verschiedenen Phasen auf:
-
Worker-Start: wenn parallele Worker initialisiert werden
-
Datenaustausch: wenn Worker Daten verarbeiten und Ergebnisse an den Leader senden
-
Worker-Shutdown: wenn die parallele Ausführung abgeschlossen ist und Worker beendet werden
-
Synchronisierungspunkte: wenn Prozesse koordiniert werden oder darauf warten müssen, dass andere Prozesse ihre Aufgaben abschließen
Das Kennen dieser Warteereignisse ist entscheidend für die Diagnose von Leistungsproblemen im Zusammenhang mit der parallelen Abfrageausführung, insbesondere in Umgebungen mit hoher Nichtsequentialität, in denen mehrere parallele Abfragen gleichzeitig ausgeführt werden.
Wahrscheinliche Ursachen für erhöhte Wartezeiten
Verschiedene Faktoren können zu einer Zunahme parallel-bezogener IPC-Warteereignisse beitragen:
- Hohe Nichtsequentialität paralleler Abfragen
-
Wenn viele parallele Abfragen gleichzeitig ausgeführt werden, kann dies zu Ressourcenkonflikten und längeren Wartezeiten für IPC-Operationen führen. Dies ist besonders häufig bei Systemen mit hohem Transaktionsvolumen oder analytischen Workloads der Fall.
- Suboptimale Pläne für parallele Abfragen
-
Wenn der Abfrageplaner ineffiziente Parallelisierungspläne auswählt, kann dies zu unnötiger Parallelisierung oder schlechter Arbeitsverteilung unter den Workern führen. Dies kann zu höheren IPC-Wartezeiten führen, insbesondere bei den Ereignissen
IPC:ExecuteGatherundIPC:ParallelFinish. Diese Planungsprobleme sind häufig auf veraltete Statistiken und „aufgeblähte“ Tabellen und Indizes zurückzuführen. - Häufiges Starten und Herunterfahren paralleler Worker
-
Kurzlebige Abfragen, die häufig parallele Worker initiieren und beenden, können zu einer Zunahme von
IPC:BgWorkerStartup- undIPC:BgWorkerShutdown-Ereignissen führen. Dies kommt oftmals bei OLTP-Workloads mit vielen kleinen, parallelisierbaren Abfragen vor. - Einschränkungen für Ressourcen
-
Eine begrenzte CPU-, Arbeitsspeicher- oder I/O-Kapazität kann zu Engpässen bei der parallelen Ausführung führen, was zu längeren Wartezeiten bei den IPC-Ereignissen führt. Wenn beispielsweise die CPU ausgelastet ist, kann es länger dauern, bis Worker-Prozesse starten oder ihren Teil der Arbeit erledigen.
- Komplexe Abfragestrukturen
-
Abfragen mit mehreren Parallelitätsebenen (z. B. parallele Joins, auf die parallele Aggregationen folgen) können zu komplexeren IPC-Mustern und potenziell längeren Wartezeiten führen, insbesondere bei
IPC:ExecuteGather-Ereignissen. - Große Ergebnismengen
-
Abfragen, die große Ergebnismengen liefern, können zu längeren
IPC:ExecuteGather-Wartezeiten führen, da der Leader-Prozess mehr Zeit damit verbringt, Ergebnisse von Worker-Prozessen zu erfassen und zu verarbeiten.
Das Kennen dieser Faktoren kann bei der Diagnose und Behebung von Leistungsproblemen im Zusammenhang mit der parallelen Abfrageausführung in Aurora PostgreSQL hilfreich sein.
Aktionen
Wenn Sie Wartezeiten im Zusammenhang mit parallelen Abfragen bemerken, bedeutet dies in der Regel, dass ein Backend-Prozess parallele Worker-Prozesse koordiniert oder auf diese wartet. Diese Wartezeiten treten häufig bei der Ausführung von Parallelisierungsplänen auf. Sie können die Auswirkungen dieser Wartezeiten untersuchen und abmildern, indem Sie die Verwendung paralleler Worker überwachen, die Parametereinstellungen überprüfen und die Abfrageausführung und Ressourcenzuweisung optimieren.
Themen
Analysieren von Abfrageplänen in Bezug auf ineffiziente Parallelität
Die parallele Ausführung von Abfragen kann häufig zu Systeminstabilität, CPU-Spitzen und unvorhersehbaren Leistungsschwankungen bei Abfragen führen. Es ist wichtig, gründlich zu analysieren, ob eine Parallelität Ihrem spezifischen Workload tatsächlich zugutekommt. Verwenden Sie EXPLAIN ANALYZE, um Pläne für die parallele Ausführung von Abfragen zu überprüfen.
Deaktivieren Sie zur Ermittlung der Planeffizienz vorübergehend die Parallelität auf Sitzungsebene:
SET max_parallel_workers_per_gather = 0; EXPLAIN ANALYZE <your_query>;
Aktivieren Sie zwecks Vergleich wieder die Parallelität:
RESET max_parallel_workers_per_gather; EXPLAIN ANALYZE <your_query>;
Wenn die Deaktivierung der Parallelität zu besseren oder konsistenteren Ergebnissen führt, sollten Sie erwägen, sie für bestimmte Abfragen auf Sitzungsebene mithilfe von SET-Befehlen zu deaktivieren. Um eine umfassendere Wirkung zu erzielen, können Sie die Parallelität auf Instance-Ebene deaktivieren, indem Sie die entsprechenden Parameter in Ihrer DB-Parametergruppe anpassen. Weitere Informationen finden Sie unter Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS.
Überwachen der Verwendung paralleler Abfragen
Verwenden Sie die folgenden Abfragen, um einen Einblick in die Aktivität und Kapazität paralleler Abfragen zu gewinnen:
Überprüfen Sie die aktiven, parallelen Worker-Prozesse:
SELECT COUNT(*) FROM pg_stat_activity WHERE backend_type = 'parallel worker';
Diese Abfrage zeigt die Anzahl der aktiven, parallelen Worker-Prozesse. Ein hoher Wert kann darauf hinweisen, dass Ihr „max_parallel_workers“ mit einem hohen Wert konfiguriert ist. Erwägen Sie, diesen zu verringern.
Überprüfen Sie gleichzeitige parallele Abfragen:
SELECT COUNT(DISTINCT leader_pid) FROM pg_stat_activity WHERE leader_pid IS NOT NULL;
Diese Abfrage gibt die Anzahl der verschiedenen Leader-Prozesse zurück, durch die parallele Abfragen gestartet wurden. Eine hohe Zahl weist hier darauf hin, dass mehrere Sitzungen gleichzeitig parallele Abfragen ausführen, was die CPU- und Speicherauslastung erhöhen kann.
Überprüfen und Anpassen von Einstellungen für parallele Abfragen
Überprüfen Sie die folgenden Parameter, um sicherzustellen, dass sie Ihrem Workload entsprechen:
-
max_parallel_workers: Gesamtzahl der parallelen Worker in allen Sitzungen -
max_parallel_workers_per_gather: Max. Worker-Anzahl pro Abfrage
Bei OLAP-Workloads kann eine Erhöhung dieser Werte die Leistung verbessern. Für OLTP-Workloads werden im Allgemeinen niedrigere Werte bevorzugt.
SHOW max_parallel_workers; SHOW max_parallel_workers_per_gather;
Optimieren der Ressourcenzuweisung
Überwachen Sie die CPU-Auslastung und ziehen Sie eine Anpassung der Anzahl der vCPUs in Betracht, wenn diese konstant hoch ist und Ihre Anwendung von parallelen Abfragen profitiert. Stellen Sie sicher, dass ausreichend Speicher für parallele Operationen verfügbar ist.
-
Ermitteln Sie anhand von Performance Insights, ob das System CPU-gebunden ist.
-
Jeder parallele Worker verwendet seinen eigenen
work_mem. Stellen Sie sicher, dass die Gesamtspeichernutzung innerhalb der Instance-Grenzen liegt.
Parallele Abfragen können erheblich mehr Ressourcen verbrauchen als nicht parallele, da jeder Worker-Prozess ein vollständig separater Prozess ist, der ungefähr die gleichen Auswirkungen auf das System hat wie eine zusätzliche Benutzersitzung. Dies sollte bei der Auswahl eines Werts für diese Einstellung sowie bei der Konfiguration anderer Einstellungen zur Steuerung der Ressourcennutzung berücksichtigt werden, zum Beispiel work_mem. Weitere Informationen finden Sie in der PostgreSQL-Dokumentationwork_mem werden individuell auf jeden Worker angewendet, das bedeutet, dass die Gesamtauslastung über alle Prozesse hinweg viel höher sein kann, als dies normalerweise für einen einzelnen Prozess der Fall wäre.
Erwägen Sie, die vCPUs zu erhöhen oder die Speicherparameter zu optimieren, wenn Ihr Workload stark parallelisiert ist.
Untersuchen der Verbindungsverwaltung
Wenn die Verbindung überlastet ist, prüfen Sie Strategien für ein Verbindungspooling der Anwendung. Erwägen Sie die Implementierung von Verbindungspooling auf Anwendungsebene, sofern es nicht bereits verwendet wird.
Überprüfen und Optimieren von Wartungsvorgängen
Koordinieren Sie die Indexerstellung und andere Wartungsaufgaben, um Ressourcenkonflikte zu vermeiden. Erwägen Sie, diese Vorgänge für Zeiten außerhalb der Spitzenzeiten einzuplanen. Vermeiden Sie es, umfangreiche Wartungsvorgänge (z. B. parallele Indexerstellungen) für Zeiten mit hoher Benutzerabfragelast einzuplanen. Diese Operationen können parallele Worker beanspruchen und die Leistung bei regulären Abfragen negativ beeinträchtigen.
