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

Eventi di attesa IPC:parallel

I seguenti IPC:parallel wait events indicano che una sessione è in attesa della comunicazione tra processi relativa alle operazioni di esecuzione di query parallele.

Versioni del motore supportate

Queste informazioni relative all’evento di attesa sono supportate per tutte le versioni di Aurora PostgreSQL.

Contesto

L’esecuzione parallela delle query in PostgreSQL implica la collaborazione di più processi per elaborare una singola query. Quando si determina che una query è adatta alla parallelizzazione, un processo leader si coordina con uno o più processi worker paralleli in base all’impostazione del parametro max_parallel_workers_per_gather. Il processo leader divide il lavoro tra i worker, ciascuno dei quali elabora la propria porzione di dati in modo indipendente, e i risultati vengono raccolti dal processo leader.

L’architettura di query parallela è composta da tre componenti principali:

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:

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 alle query parallele:

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 verificano attese relative a query parallele, in genere significa che un processo di backend sta coordinando o attendendo processi worker paralleli. Queste attese sono comuni durante l’esecuzione di piani paralleli. È possibile analizzare e mitigare l’impatto di queste attese monitorando l’utilizzo dei worker paralleli, esaminando le impostazioni dei parametri e ottimizzando l’esecuzione delle query e l’allocazione delle risorse.

Analizzare i piani di query per individuare eventuali parallelismi inefficienti

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. Utilizzare EXPLAIN ANALYZE per esaminare i piani di esecuzione delle query parallele.

Disattivare temporaneamente il parallelismo a livello di sessione per confrontare l’efficienza del piano:

SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;
            

Riattivare il parallelismo e confrontare:

RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE <your_query>;
            

Se la disabilitazione del parallelismo produce risultati migliori o più coerenti, prendere in considerazione la possibilità di disabilitarlo per query specifiche a livello di sessione utilizzando i comandi SET. Per un impatto più ampio, è possibile voler disabilitare il parallelismo a livello di istanza regolando i parametri pertinenti nel cluster o nel gruppo di parametri dell’istanza. Per ulteriori informazioni, consulta Amazon Aurora PostgreSQL parametri.

Monitorare l’utilizzo delle query parallele

Utilizzare le seguenti query per ottenere visibilità sull’attività e sulla capacità delle query parallele:

Controllare i processi worker paralleli attivi:

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

Questa query mostra il numero di processi worker paralleli attivi. Un valore elevato può indicare che `max_parallel_workers` è configurato con un valore elevato e potrebbe essere opportuno ridurlo.

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

Esaminare e modificare le impostazioni delle interrogazioni parallele

Controllare i seguenti parametri per assicurarsi che siano in linea con il carico di lavoro:

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;
            

Ottimizzare l’allocazione delle risorse

Monitorare l’utilizzo della CPU e valutare la possibilità di modificare il numero di vCPU se è costantemente elevato e se l’applicazione trae vantaggio dalle query parallele. Assicurarsi che sia disponibile una memoria adeguata per le operazioni parallele.

Le query parallele possono consumare molte più risorse rispetto alle query non parallele, poiché ogni processo worker è 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 come work_mem. Per ulteriori informazioni, consultare la documentazione di PostgreSQL. I limiti delle risorse come work_mem vengono applicati individualmente a ciascun worker, 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.

Prendere in considerazione l’aumento delle vCPU o l’ottimizzazione dei parametri di memoria se il carico di lavoro è fortemente parallelizzato.

Esaminare la gestione delle connessioni

In caso di esaurimento delle connessioni, esaminare le strategie di pooling delle connessioni dell’applicazione. Prendere in considerazione l’implementazione del pooling delle connessioni a livello di applicazione, se non è già in uso.

Esaminare e ottimizzare le operazioni di manutenzione

Coordinare la creazione degli indici e le altre attività di manutenzione per prevenire il conflitto di risorse. Prendere in considerazione la possibilità di pianificare queste operazioni durante le ore non di picco. Evitare di pianificare una manutenzione intensa (ad esempio, build di indici paralleli) durante i periodi di elevato carico di query da parte degli utenti. Queste operazioni possono consumare worker paralleli e influire sulle prestazioni delle query regolari.

Utilizzare Query Plan Management (QPM)

In Aurora PostgreSQL, la funzionalità Query Plan Management (QPM) è progettata per garantire l’adattabilità e la stabilità del piano indipendentemente dalle modifiche apportate all’ambiente di database che potrebbero causare la regressione del piano di query. Per maggiori informazioni, consulta Panoramica della gestione del piano di query per Aurora PostgreSQL. QPM fornisce un certo controllo sull’ottimizzatore. Esaminare i piani approvati in QPM per assicurarsi che siano in linea con le attuali impostazioni di parallelismo. Aggiornare o rimuovere i piani obsoleti che potrebbero forzare un’esecuzione parallela non ottimale.

È anche possibile correggere i piani utilizzando pg_hint_plan. Per ulteriori informazioni, consulta Correzione dei piani mediante pg_hint_plan. È possibile utilizzare l’hint denominato Parallel per imporre l’esecuzione parallela. Per maggiori informazioni, consulta la pagina relativa agli hint per i piani paralleli.