Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
IPC:eventi di attesa paralleli
Quanto segue IPC:parallel wait events indica che una sessione è in attesa della comunicazione tra processi relativa alle operazioni di esecuzione di query parallele.
-
IPC:BgWorkerStartup- Un processo è in attesa che un processo di lavoro parallelo completi la sequenza di avvio. Ciò accade quando si inizializzano i worker per l'esecuzione di query parallele. -
IPC:BgWorkerShutdown- Un processo è in attesa che un processo di lavoro parallelo completi la sequenza di spegnimento. Ciò si verifica durante la fase di pulizia dell'esecuzione di query parallele. -
IPC:ExecuteGather- Un processo è in attesa di ricevere dati dai processi di lavoro paralleli durante l'esecuzione delle query. Ciò si verifica quando il processo leader deve raccogliere risultati dai suoi lavoratori. -
IPC:ParallelFinish- Un processo è in attesa che i lavoratori paralleli completino l'esecuzione e riportino i risultati finali. Ciò avviene durante la fase di completamento dell'esecuzione delle query parallele.
Versioni del motore supportate
Queste informazioni relative all'evento di attesa sono supportate per tutte el versioni di Aurora PostgreSQL.
Context
L'esecuzione parallela delle query in PostgreSQL implica la collaborazione di più processi per elaborare una singola query. Quando si determina che un'interrogazione è adatta alla parallelizzazione, un processo leader si coordina con uno o più processi di lavoro paralleli in base all'max_parallel_workers_per_gatherimpostazione dei parametri. Il processo leader divide il lavoro tra i lavoratori, ogni lavoratore elabora la propria parte di dati in modo indipendente e i risultati vengono raccolti nel processo principale.
Nota
Ogni worker parallelo opera come un processo separato con requisiti di risorse simili a quelli di una sessione utente completa. Ciò significa che una query parallela con 4 worker può consumare fino a 5 volte le risorse (CPU, memoria, I/O larghezza di banda) rispetto a una query non parallela, poiché sia il processo leader che ogni processo di lavoro mantengono le proprie allocazioni di risorse. Ad esempio, impostazioni come quelle work_mem vengono applicate singolarmente a ciascun lavoratore, moltiplicando potenzialmente l'utilizzo totale della memoria in tutti i processi.
L'architettura di interrogazione parallela è composta da tre componenti principali:
-
Processo leader: il processo principale che avvia l'operazione parallela, divide il carico di lavoro e si coordina con i processi di lavoro.
-
Processi di lavoro: processi in background che eseguono parti della query in parallelo.
-
Gather/Gather merge: operazioni che combinano i risultati di più processi di lavoro e li restituiscono al leader
Durante l'esecuzione parallela, i processi devono comunicare tra loro tramite meccanismi di comunicazione tra processi (IPC). Questi eventi di attesa IPC si verificano durante diverse fasi:
-
Avvio del lavoratore: quando i worker paralleli vengono inizializzati
-
Scambio di dati: quando i lavoratori elaborano i dati e inviano i risultati al leader
-
Arresto del lavoratore: quando l'esecuzione parallela viene completata e i lavoratori vengono terminati
-
Punti di sincronizzazione: quando i processi devono coordinarsi o attendere che altri processi completino le proprie attività
La comprensione di questi eventi di attesa è fondamentale per diagnosticare i problemi di prestazioni relativi all'esecuzione di query parallele, specialmente in ambienti ad alta concorrenza in cui più query parallele possono essere eseguite contemporaneamente.
Probabili cause di aumento delle attese
Diversi fattori possono contribuire a un aumento degli eventi di attesa IPC correlati al parallelo:
- Elevata concorrenza di query parallele
-
L'esecuzione simultanea di più query parallele può portare a un conflitto di risorse e a un aumento dei tempi di attesa per le operazioni IPC. Ciò è particolarmente comune nei sistemi con elevati volumi di transazioni o carichi di lavoro analitici.
- Piani di interrogazione parallela non ottimali
-
Se il pianificatore di query sceglie piani paralleli inefficienti, ciò può comportare una parallelizzazione non necessaria o una scarsa distribuzione del lavoro tra i lavoratori. Ciò può portare a un aumento delle attese IPC, in particolare per gli eventi.
IPC:ExecuteGatherIPC:ParallelFinishQuesti problemi di pianificazione spesso derivano da statistiche obsolete e dal rigonfiamento. table/index - Avvio e arresto frequenti dei lavoratori paralleli
-
Le interrogazioni di breve durata che avviano e interrompono frequentemente i parallel worker possono causare un aumento degli eventi AND.
IPC:BgWorkerStartupIPC:BgWorkerShutdownCiò si verifica spesso nei carichi di lavoro OLTP con molte piccole query parallelizzabili. - Vincoli delle risorse
-
CPU, memoria o I/O capacità limitate possono causare colli di bottiglia nell'esecuzione parallela, con conseguente aumento dei tempi di attesa in tutti gli eventi IPC. Ad esempio, se la CPU è satura, i processi di lavoro potrebbero impiegare più tempo per avviarsi o elaborare la relativa parte di lavoro.
- Strutture di interrogazione complesse
-
Le interrogazioni con più livelli di parallelismo (ad esempio, join paralleli seguiti da aggregazioni parallele) possono portare a modelli IPC più complessi e tempi di attesa potenzialmente maggiori, soprattutto per gli eventi.
IPC:ExecuteGather - Serie di risultati di grandi dimensioni
-
Le interrogazioni che producono set di risultati di grandi dimensioni possono aumentare i tempi di
IPC:ExecuteGatherattesa poiché il processo leader dedica più tempo alla raccolta e all'elaborazione dei risultati dei processi di lavoro.
La comprensione di questi fattori può aiutare a diagnosticare e risolvere i problemi di prestazioni relativi all'esecuzione di query parallele in Aurora PostgreSQL.
Azioni
Quando si vedono attese relative alle interrogazioni parallele, in genere significa che un processo di backend sta coordinando o è in attesa dei processi di lavoro paralleli. Queste attese sono comuni durante l'esecuzione di piani paralleli. È possibile analizzare e mitigare l'impatto di queste attese monitorando l'utilizzo dei lavoratori paralleli, rivedendo le impostazioni dei parametri e ottimizzando l'esecuzione delle query e l'allocazione delle risorse.
Argomenti
Analizza i piani di interrogazione per verificare la presenza di un parallelismo inefficiente
L'esecuzione parallela delle query può spesso portare a instabilità del sistema, picchi di CPU e variazioni imprevedibili delle prestazioni delle query. È fondamentale analizzare a fondo se il parallelismo migliora effettivamente il carico di lavoro specifico. Usa EXPLAIN ANALYZE per esaminare i piani di esecuzione delle query parallele.
Disattiva temporaneamente il parallelismo a livello di sessione per confrontare l'efficienza del piano:
SET max_parallel_workers_per_gather = 0; EXPLAIN ANALYZE <your_query>;
Riattiva il parallelismo e confronta:
RESET max_parallel_workers_per_gather; EXPLAIN ANALYZE <your_query>;
Se la disabilitazione del parallelismo produce risultati migliori o più coerenti, prendi in considerazione la possibilità di disabilitarlo per query specifiche a livello di sessione utilizzando i comandi SET. Per un impatto più ampio, potresti voler disabilitare il parallelismo a livello di istanza regolando i parametri pertinenti nel gruppo di parametri del database. Per ulteriori informazioni, consulta .
Monitora l'utilizzo delle query parallele
Utilizza le seguenti query per ottenere visibilità sull'attività e sulla capacità delle query parallele:
Controlla i processi di lavoro paralleli attivi:
SELECT COUNT(*) FROM pg_stat_activity WHERE backend_type = 'parallel worker';
Questa query mostra il numero di processi di lavoro paralleli attivi. Un valore elevato può indicare che il tuo `max_parallel_workers` è configurato con un valore elevato e potresti prendere in considerazione la possibilità di ridurlo.
Controlla le query parallele simultanee:
SELECT COUNT(DISTINCT leader_pid) FROM pg_stat_activity WHERE leader_pid IS NOT NULL;
Questa query restituisce il numero di processi leader distinti che hanno avviato query parallele. Un numero elevato indica che più sessioni eseguono query parallele contemporaneamente, il che può aumentare la richiesta di CPU e memoria.
Rivedi e modifica le impostazioni delle interrogazioni parallele
Controlla i seguenti parametri per assicurarti che siano in linea con il tuo carico di lavoro:
-
max_parallel_workers: numero totale di worker paralleli in tutte le sessioni. -
max_parallel_workers_per_gather: numero massimo di lavoratori per query.
Per i carichi di lavoro OLAP, l'aumento di questi valori può migliorare le prestazioni. Per i carichi di lavoro OLTP, in genere sono preferiti valori inferiori.
SHOW max_parallel_workers; SHOW max_parallel_workers_per_gather;
Ottimizza l'allocazione delle risorse
Monitora l'utilizzo della CPU e valuta la possibilità di regolare il numero di v CPUs se è costantemente elevato e se l'applicazione trae vantaggio dalle query parallele. Assicurarsi che sia disponibile una memoria adeguata per le operazioni parallele.
-
Utilizza le metriche di Performance Insights per determinare se il sistema è legato alla CPU.
-
Ogni worker parallelo utilizza il proprio
work_mem. Assicurati che l'utilizzo totale della memoria rientri nei limiti delle istanze.
Le interrogazioni parallele possono consumare molte più risorse rispetto alle interrogazioni non parallele, poiché ogni processo di lavoro è un processo completamente separato che ha all'incirca lo stesso impatto sul sistema di una sessione utente aggiuntiva. Questo deve essere tenuto in considerazione quando si sceglie un valore per questa impostazione, nonché quando si configurano altre impostazioni che controllano l'utilizzo delle risorse, ad esempio. work_mem Per ulteriori informazioni, consultare la documentazione di PostgreSQLwork_mem vengono applicati individualmente a ciascun lavoratore, il che significa che l'utilizzo totale può essere molto più elevato in tutti i processi rispetto a quanto sarebbe normalmente per ogni singolo processo.
Prendi in considerazione l'aumento di v CPUs o l'ottimizzazione dei parametri di memoria se il carico di lavoro è fortemente parallelizzato.
Esamina la gestione delle connessioni
In caso di esaurimento della connessione, esaminate le strategie di pool di connessioni delle applicazioni. Prendi in considerazione l'implementazione del pool di connessioni a livello di applicazione, se non è già in uso.
Rivedi e ottimizza le operazioni di manutenzione
Coordina la creazione degli indici e le altre attività di manutenzione per prevenire il conflitto di risorse. Prendi in considerazione la possibilità di pianificare queste operazioni durante le ore non di punta. Evita di pianificare interventi di manutenzione impegnativi (ad esempio, compilazioni di indici paralleli) durante i periodi di elevato carico di query da parte degli utenti. Queste operazioni possono consumare lavoratori paralleli e influire sulle prestazioni per le query regolari.
