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:Parallele Warteereignisse

Die folgenden IPC:parallel wait events Hinweise deuten darauf hin, dass eine Sitzung auf die Kommunikation zwischen Prozessen im Zusammenhang mit parallel Abfrageausführungen wartet.

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 sich ein führender Prozess auf der Grundlage der max_parallel_workers_per_gather Parametereinstellung mit einem oder mehreren parallel Worker-Prozessen. Der Leader-Prozess teilt die Arbeit auf die einzelnen Mitarbeiter auf, jeder Mitarbeiter verarbeitet seinen Teil der Daten unabhängig, und die Ergebnisse werden an den Leader-Prozess zurückgemeldet.

Die parallel Abfragearchitektur besteht aus drei Hauptkomponenten:

Während der parallel Ausführung müssen Prozesse über IPC-Mechanismen (Inter-Process Communication) miteinander kommunizieren. Diese IPC-Warteereignisse treten in verschiedenen Phasen auf:

Das Verständnis dieser Warteereignisse ist entscheidend für die Diagnose von Leistungsproblemen im Zusammenhang mit der parallel Abfrageausführung, insbesondere in Umgebungen mit hoher Parallelität, in denen mehrere parallel Abfragen gleichzeitig ausgeführt werden können.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Verschiedene Faktoren können zu einer Zunahme parallelbedingter IPC-Warteereignisse beitragen:

Das Verständnis dieser Faktoren kann bei der Diagnose und Behebung von Leistungsproblemen im Zusammenhang mit der parallel Abfrageausführung in Aurora PostgreSQL hilfreich sein.

Aktionen

Wenn Sie Wartezeiten im Zusammenhang mit parallel Abfragen sehen, bedeutet dies in der Regel, dass ein Backend-Prozess parallel Worker-Prozesse koordiniert oder darauf wartet. Diese Wartezeiten treten häufig bei der Ausführung parallel Pläne auf. Sie können die Auswirkungen dieser Wartezeiten untersuchen und abmildern, indem Sie die parallel Worker-Nutzung überwachen, die Parametereinstellungen überprüfen und die Abfrageausführung und die Ressourcenzuweisung optimieren.

Analysieren Sie Abfragepläne 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 Parallelität Ihre spezifische Arbeitslast tatsächlich verbessert. Verwenden Sie EXPLAIN ANALYZE, um Pläne parallel Ausführung von Abfragen zu überprüfen.

Deaktivieren Sie vorübergehend die Parallelität auf Sitzungsebene, um die Effizienz des Plans zu vergleichen:

SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;
            

Aktivieren Sie die Parallelität erneut und vergleichen Sie:

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, sollten Sie die Parallelität auf Instanzebene deaktivieren, indem Sie die entsprechenden Parameter in Ihrem Cluster oder Ihrer Instance-Parametergruppe anpassen. Weitere Informationen finden Sie unter Amazon-Aurora-PostgreSQL-Parameter.

Überwachen Sie die Verwendung parallel Abfragen

Verwenden Sie die folgenden Abfragen, um Einblick in die Aktivität und Kapazität parallel Abfragen zu erhalten:

Überprüfen Sie die aktiven parallel Worker-Prozesse:

SELECT
    COUNT(*)
FROM
    pg_stat_activity
WHERE
    backend_type = 'parallel worker';
            

Diese Abfrage zeigt die Anzahl der aktiven parallel Worker-Prozesse. Ein hoher Wert kann darauf hinweisen, dass Ihr `max_parallel_workers` mit einem hohen Wert konfiguriert ist, und Sie sollten erwägen, diesen zu reduzieren.

Überprüfen Sie gleichzeitige parallel Abfragen:

SELECT
    COUNT(DISTINCT leader_pid)
FROM
    pg_stat_activity
WHERE
    leader_pid IS NOT NULL;
            

Diese Abfrage gibt die Anzahl der unterschiedlichen Leader-Prozesse zurück, die parallel Abfragen gestartet haben. Eine hohe Zahl weist hier darauf hin, dass mehrere Sitzungen parallel Abfragen gleichzeitig ausführen, was die CPU- und Speicherbelastung erhöhen kann.

Einstellungen für parallel Abfragen überprüfen und anpassen

Überprüfen Sie die folgenden Parameter, um sicherzustellen, dass sie mit Ihrer Arbeitslast übereinstimmen:

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 Sie die Ressourcenzuweisung

Überwachen Sie die CPU-Auslastung und erwägen Sie, die Anzahl von v CPUs anzupassen, wenn sie konstant hoch ist und Ihre Anwendung von parallel Abfragen profitiert. Stellen Sie sicher, dass ausreichend Speicher für parallel Operationen verfügbar ist.

Die parallel Abfragen können erheblich mehr Ressourcen verbrauchen als nicht parallele Abfragen, da jeder Arbeitsprozess ein völlig 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, z. B. work_mem Weitere Informationen finden Sie in der PostgreSQL-Dokumentation. Ressourcenbegrenzungen, wie work_mem sie für jeden Worker individuell gelten, 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, v zu erhöhen CPUs oder die Speicherparameter zu optimieren, wenn Ihre Arbeitslast stark parallelisiert ist.

Untersuchen Sie das Verbindungsmanagement

Wenn die Verbindung erschöpft ist, überprüfen Sie die Strategien für das Verbindungspooling der Anwendung. Erwägen Sie die Implementierung von Verbindungspooling auf Anwendungsebene, sofern es nicht bereits verwendet wird.

Überprüfen und optimieren Sie die Wartungsarbeiten

Koordinieren Sie die Indexerstellung und andere Wartungsaufgaben, um Ressourcenkonflikte zu vermeiden. Erwägen Sie, diese Operationen außerhalb der Spitzenzeiten zu planen. Vermeiden Sie es, umfangreiche Wartungsarbeiten (z. B. parallel Indexerstellungen) in Zeiten hoher Benutzerabfragelast einzuplanen. Diese Operationen können parallel Worker beanspruchen und die Leistung bei regulären Abfragen beeinträchtigen.

Nutzen Sie Query Plan Management (QPM)

In Aurora PostgreSQL wurde die Funktion Query Plan Management (QPM) entwickelt, um die Anpassungsfähigkeit und Stabilität des Plans zu gewährleisten, unabhängig von Änderungen in der Datenbankumgebung, die zu einer Regression des Abfrageplans führen könnten. Weitere Informationen finden Sie unter Übersicht über die Abfrageplanverwaltung in Aurora PostgreSQL .QPM bietet eine gewisse Kontrolle über den Optimierer. Überprüfen Sie die genehmigten Pläne in QPM, um sicherzustellen, dass sie den aktuellen Parallelitätseinstellungen entsprechen. Aktualisieren oder entfernen Sie veraltete Pläne, die möglicherweise eine suboptimale parallel Ausführung erzwingen.

Sie können die Pläne auch mit pg_hint_plan korrigieren. Weitere Informationen finden Sie unter Reparieren von Plänen mit pg_hint_plan. Sie können den genannten Hinweis verwendenParallel, um die parallel Ausführung zu erzwingen. Weitere Informationen finden Sie in den Hinweisen für parallel Pläne.