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.

Bewährte Methoden für parallele Abfragen in

Die parallele Abfrageausführung ist eine Funktion in PostgreSQL, mit der eine einzelne SQL-Abfrage in kleinere Aufgaben aufgeteilt werden kann, die gleichzeitig von mehreren Hintergrund-Worker-Prozessen verarbeitet werden. Anstatt eine Abfrage vollständig in einem einzigen Backend-Prozess auszuführen, kann PostgreSQL Teile der Abfrage, wie Scans, Joins, Aggregationen oder Sortierungen, auf mehrere CPU-Kerne verteilen. Der Leader-Prozess koordiniert diese Ausführung und sammelt die Ergebnisse der parallel Mitarbeiter.

Für die meisten Produktionsworkloads, insbesondere OLTP-Systeme mit hoher Parallelität, empfehlen wir jedoch, die automatische parallel Abfrageausführung zu deaktivieren. Parallelität kann zwar Abfragen großer Datenmengen bei Analyse- oder Berichtsworkloads beschleunigen, birgt jedoch erhebliche Risiken, die in geschäftigen Produktionsumgebungen häufig die Vorteile überwiegen.

Die parallele Ausführung bringt auch einen erheblichen Mehraufwand mit sich. Jeder parallel Worker ist ein vollständiger PostgreSQL-Backend-Prozess, der Prozessforking (Kopieren von Speicherstrukturen und Initialisieren des Prozessstatus) und Authentifizierung (Nutzung von Verbindungssteckplätzen von Ihrem Limit) erfordert. max_connections Jeder Worker verbraucht außerdem seinen eigenen Speicher, auch work_mem für Sortier- und Hashing-Operationen. Bei mehreren Workern pro Abfrage vervielfacht sich die Speicherbelegung schnell (z. B. 4 Worker × 64 MB = 256 MB pro Abfrage). work_mem Aus diesem Grund können parallel Abfragen erheblich mehr Systemressourcen verbrauchen als Abfragen mit einem einzigen Prozess. Wenn sie nicht richtig eingestellt sind, können sie zu CPU-Sättigung (mehrere Worker überfordern die verfügbare Verarbeitungskapazität), verstärktem Kontextwechsel (das Betriebssystem wechselt häufig zwischen zahlreichen Worker-Prozessen, was den Overhead erhöht und den Durchsatz reduziert) oder zu Verbindungsausfällen führen (da jeder parallel Worker einen Verbindungssteckplatz beansprucht, verwendet eine einzelne Abfrage mit 4 Workern insgesamt 5 Verbindungen, 1 Leader und 4 Worker, was Ihren Verbindungspool bei hoher Parallelität schnell erschöpfen kann, wodurch neue Clientverbindungen verhindert und Anwendungsausfälle verursacht werden). Diese Probleme sind besonders schwerwiegend bei Workloads mit hoher Parallelität, bei denen mehrere Abfragen versuchen können, gleichzeitig ausgeführt zu werden.

PostgreSQL entscheidet auf der Grundlage von Kostenschätzungen, ob Parallelität verwendet werden soll. In einigen Fällen kann der Planer automatisch zu einem Parallelplan wechseln, wenn dieser günstiger erscheint, auch wenn er in der Praxis nicht ideal ist. Dies kann der Fall sein, wenn Indexstatistiken veraltet sind oder wenn durch Aufblähung sequentielle Scans attraktiver erscheinen als Indexsuchen. Aufgrund dieses Verhaltens können automatische parallel Pläne manchmal zu Regressionen bei der Abfrageleistung oder Systemstabilität führen.

Um den größtmöglichen Nutzen aus parallel Abfragen in zu ziehen, ist es wichtig, sie auf der Grundlage Ihrer Arbeitslast zu testen und zu optimieren, die Auswirkungen auf das System zu überwachen und die automatische parallel Planauswahl zugunsten der Steuerung auf Abfrageebene zu deaktivieren.

Konfigurationsparameter

PostgreSQL verwendet mehrere Parameter, um das Verhalten und die Verfügbarkeit parallel Abfragen zu steuern. Diese zu verstehen und zu optimieren, ist entscheidend, um eine vorhersehbare Leistung zu erzielen:

Wichtige Überlegungen

Identifizieren Sie die Nutzung paralleler Abfragen

Abfragen können zu parallel Plänen wechseln, die auf Datenverteilung oder Statistiken basieren. Beispiel:

SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';

Diese Abfrage verwendet möglicherweise einen Index für aktuelle Daten, wechselt jedoch zu einem parallel sequentiellen Scan für historische Daten.

Sie können Ausführungspläne für Abfragen protokollieren, indem Sie das auto_explain Modul laden. Weitere Informationen finden Sie im AWS Knowledge Center unter Ausführungspläne von Abfragen protokollieren.

Sie können CloudWatch Database Insights auf Warteereignisse im Zusammenhang mit parallelen Abfragen überwachen. Weitere Informationen zu Warteereignissen im Zusammenhang mit Parallel Query finden Sie unter IPC:Parallele Warteereignisse

Ab PostgreSQL Version 18 können Sie parallel Worker-Aktivitäten mithilfe neuer Spalten in pg_stat_databaseund überwachen: pg_stat_statements

Diese Kennzahlen helfen dabei, Diskrepanzen zwischen der geplanten und der tatsächlichen Parallelität zu erkennen, die auf Ressourcenbeschränkungen oder Konfigurationsprobleme hinweisen können. Verwenden Sie die folgenden Abfragen, um die parallel Ausführung zu überwachen:

Für Parallel-Worker-Metriken auf Datenbankebene:

SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();

Für Parallel-Worker-Metriken auf Abfrageebene

SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;

Wie kontrolliert man Parallelität

Es gibt mehrere Möglichkeiten, die Abfrageparallelität zu kontrollieren, die jeweils für unterschiedliche Szenarien und Anforderungen konzipiert sind.

Um die automatische Parallelität global zu deaktivieren, und legen Sie Folgendes fest:

max_parallel_workers_per_gather = 0;

Für persistente, benutzerspezifische Einstellungen bietet der Befehl ALTER ROLE eine Möglichkeit, Parameter festzulegen, die für alle future Sitzungen eines bestimmten Benutzers gelten.

Beispiel:

ALTER ROLE username SET max_parallel_workers_per_gather = 4;stellt sicher, dass jedes Mal, wenn dieser Benutzer eine Verbindung zur Datenbank herstellt, seine Sitzungen bei Bedarf diese Parallel-Worker-Einstellung verwenden.

Die Steuerung auf Sitzungsebene kann mit dem Befehl SET erreicht werden, der die Parameter für die Dauer der aktuellen Datenbanksitzung ändert. Dies ist besonders nützlich, wenn Sie Einstellungen vorübergehend anpassen müssen, ohne dass dies Auswirkungen auf andere Benutzer oder future Sitzungen hat. Einmal festgelegt, bleiben diese Parameter gültig, bis sie explizit zurückgesetzt werden oder bis die Sitzung beendet wird. Die Befehle sind einfach:

SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;

Für eine noch detailliertere Steuerung können Sie mit SET LOCAL die Parameter für eine einzelne Transaktion ändern. Dies ist ideal, wenn Sie die Einstellungen für einen bestimmten Satz von Abfragen innerhalb einer Transaktion anpassen müssen. Danach werden die Einstellungen automatisch auf ihre vorherigen Werte zurückgesetzt. Dieser Ansatz trägt dazu bei, unbeabsichtigte Auswirkungen auf andere Vorgänge innerhalb derselben Sitzung zu verhindern.

Diagnostizieren des Verhaltens paralleler Abfragen

Wird verwendetEXPLAIN (ANALYZE, VERBOSE), um zu überprüfen, ob eine Abfrage parallel ausgeführt wurde:

So deaktivieren Sie die Parallelität vorübergehend zum Vergleich:

SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;
RESET max_parallel_workers_per_gather;