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.

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.

L'architettura di interrogazione 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 possono essere eseguite più query parallele contemporaneamente.

Probabili cause di aumento delle attese

Diversi fattori possono contribuire a un aumento degli eventi di attesa IPC correlati al parallelo:

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.

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 cluster o nel gruppo di parametri di istanza. Per ulteriori informazioni, consulta Amazon Aurora PostgreSQL parametri.

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:

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.

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 PostgreSQL. I limiti delle risorse, ad esempio, work_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. Valuta 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.

Utilizza 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 all'ambiente del database che potrebbero causare la regressione del piano di query. Per ulteriori informazioni, consulta Panoramica della gestione del piano di query per Aurora PostgreSQL .QPM fornisce un certo controllo sull'ottimizzatore. Rivedi i piani approvati in QPM per assicurarti che siano in linea con le attuali impostazioni di parallelismo. Aggiorna o rimuovi i piani obsoleti che potrebbero forzare un'esecuzione parallela non ottimale.

Puoi anche correggere i piani usando pg_hint_plan. Per ulteriori informazioni, consulta Correzione dei piani mediante pg_hint_plan. È possibile utilizzare il suggerimento denominato Parallel per imporre l'esecuzione parallela. Per ulteriori informazioni, consulta i Suggerimenti per i piani paralleli.