IPC: eventos de espera paralelos - Amazon Aurora
Versões compatíveis do mecanismoContextoPossíveis causas do maior número de esperasAções

IPC: eventos de espera paralelos

Os seguintes IPC:parallel wait events indicam que uma sessão está aguardando a comunicação entre processos relacionada às operações de execução paralela de consultas.

  • IPC:BgWorkerStartup - um processo está aguardando um processo de operador concluir sua sequência de inicialização. Isso acontece ao inicializar operadores para execução paralela de consultas.

  • IPC:BgWorkerShutdown - um processo está aguardando um processo de operador concluir sua sequência de shutdown. Isso ocorre durante a fase de limpeza da execução paralela da consulta.

  • IPC:ExecuteGather - um processo está aguardando para receber dados de processos de operador paralelos durante a execução da consulta. Isso ocorre quando o processo líder precisa coletar resultados de seus operadores.

  • IPC:ParallelFinish - um processo está aguardando operadores paralelos terminarem sua execução e relatarem seus resultados finais. Isso acontece durante a fase de conclusão da execução paralela da consulta.

Versões compatíveis do mecanismo

Essas informações de eventos de espera têm suporte para todas as versões do Aurora PostgreSQL.

Contexto

A execução paralela de consultas no PostgreSQL envolve vários processos trabalhando juntos para processar uma única consulta. Quando uma consulta é determinada como adequada para paralelização, um processo líder se coordena com um ou mais processos de operador paralelos com base na configuração de parâmetros max_parallel_workers_per_gather. O processo líder divide o trabalho entre os operadores, cada um processa sua parte dos dados de forma independente e os resultados são reunidos de volta ao processo líder.

nota

Cada operador paralelo opera como um processo separado com requisitos de recursos semelhantes a uma sessão completa de usuário. Isso significa que uma consulta paralela com 4 operadores pode consumir até 5 vezes mais recursos (CPU, memória, largura de banda de E/S) em comparação com uma consulta não paralela, pois tanto o processo líder quanto cada processo de operador mantêm suas próprias alocações de recursos. Por exemplo, configurações como work_mem são aplicadas individualmente a cada operador, potencialmente multiplicando o uso total de memória em todos os processos.

A arquitetura de consulta paralela consiste em três componentes principais:

  • Processo líder: o processo principal que inicia a operação paralela, divide a workload e coordena com os processos de operador.

  • Processos de operador: processos em segundo plano que executam partes da consulta em paralelo.

  • Fusão Gather/Gather: operações que combinam resultados de vários processos de operador de volta ao líder

Durante a execução paralela, os processos precisam se comunicar entre si por meio de mecanismos de comunicação entre processos (IPC). Esses eventos de espera do IPC ocorrem durante diferentes fases:

  • Inicialização do operador: quando operadores paralelos estão sendo inicializados

  • Troca de dados: quando os operadores estão processando dados e enviando resultados para o líder

  • Encerramento do operador: quando a execução paralela é concluída e os operadores estão sendo encerrados

  • Pontos de sincronização: quando os processos precisam se coordenar ou esperar que outros processos concluam suas tarefas

Compreender esses eventos de espera é crucial para diagnosticar problemas de desempenho relacionados à execução paralela de consultas, especialmente em ambientes de alta concorrência, nos quais várias consultas paralelas podem ser executadas simultaneamente.

Possíveis causas do maior número de esperas

Vários fatores podem contribuir para um aumento nos eventos de espera do IPC relacionados ao paralelismo:

Alta concorrência de consultas paralelas

Quando muitas consultas paralelas são executadas simultaneamente, isso pode levar à contenção de recursos e ao aumento do tempo de espera para operações de IPC. Isso é particularmente comum em sistemas com altos volumes de transações ou workloads analíticas.

Planos de consulta paralela subótimos

Se o planejador de consultas escolher planos paralelos ineficientes, isso poderá resultar em paralelização desnecessária ou má distribuição do trabalho entre os operadores. Isso pode levar ao aumento das esperas de IPC, especialmente para eventos IPC:ExecuteGather e IPC:ParallelFinish. Esses problemas de planejamento geralmente resultam de estatísticas desatualizadas e do inchaço da tabela/índice.

Inicialização e encerramento frequentes de operadores paralelos

Consultas de curta duração que frequentemente iniciam e encerram operadores paralelos podem causar um aumento nos eventos IPC:BgWorkerStartup e IPC:BgWorkerShutdown. Isso geralmente é visto em workloads OLTP com muitas consultas pequenas e paralelizáveis.

Restrições de recursos

A capacidade limitada de CPU, memória ou E/S pode causar gargalos na execução paralela, levando ao aumento do tempo de espera em todos os eventos de IPC. Por exemplo, se a CPU estiver saturada, os processos de operador podem levar mais tempo para iniciar ou processar sua parte do trabalho.

Estruturas complexas de consulta

Consultas com vários níveis de paralelismo (por exemplo, junções paralelas seguidas por agregações paralelas) podem levar a padrões de IPC mais complexos e a tempos de espera potencialmente maiores, especialmente para eventos IPC:ExecuteGather.

Conjuntos de resultados grandes

Consultas que produzem grandes conjuntos de resultados podem causar maiores tempos de espera IPC:ExecuteGather, pois o processo líder passa mais tempo coletando e processando resultados dos processos de operador.

Entender esses fatores pode ajudar a diagnosticar e resolver problemas de desempenho relacionados à execução paralela de consultas no Aurora PostgreSQL.

Ações

Quando você vê esperas relacionadas à consulta paralela, isso normalmente significa que um processo de backend está coordenando ou aguardando processos de operador paralelos. Essas esperas são comuns durante a execução de planos paralelos. Você pode investigar e mitigar o impacto dessas esperas monitorando o uso de operadores paralelos, revisando as configurações de parâmetros e ajustando a execução da consulta e a alocação de recursos.

Analisar planos de consulta para paralelismo ineficiente

A execução paralela de consultas pode frequentemente levar à instabilidade do sistema, picos de CPU e variações imprevisíveis no desempenho da consulta. É crucial analisar minuciosamente se o paralelismo realmente melhora sua workload específica. Use EXPLAIN ANALYZE para revisar os planos de execução de consultas paralelas.

Desative temporariamente o paralelismo no nível da sessão para comparar a eficiência do plano:


SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;

Reative o paralelismo e compare:


RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE <your_query>;

Se a desativação do paralelismo produzir resultados melhores ou mais consistentes, desative-o para consultas específicas no nível da sessão usando os comandos SET. Para um impacto mais amplo, você pode querer desabilitar o paralelismo no nível da instância ajustando os parâmetros relevantes em seu grupo de parâmetros do cluster ou instância. Para obter mais informações, consulte Amazon Aurora PostgreSQL parameters.

Monitorar o uso de consultas paralelas

Use as consultas a seguir para obter visibilidade da atividade e da capacidade de consultas paralelas:

Verifique os processos de operador paralelos ativos:


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

Esta consulta mostra o número de processos de operador paralelos ativos. Um valor alto pode indicar que seu `max_parallel_workers` está configurado com um valor alto e você pode querer reduzi-lo.

Verifique as consultas paralelas simultâneas:


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

Essa consulta retorna o número de processos líderes distintos que iniciaram consultas paralelas. Um número alto aqui indica que várias sessões estão executando consultas paralelas simultaneamente, o que pode aumentar a demanda de CPU e memória.

Revisar e ajustar as configurações de consulta paralela

Analise os seguintes parâmetros para garantir que estejam alinhados à sua workload:

  • max_parallel_workers: número total de workers paralelos em todas as sessões.

  • max_parallel_workers_per_gather: máximo de workers por consulta.

Para workloads OLAP, aumentar esses valores pode melhorar o desempenho. Para workloads OLTP, valores mais baixos geralmente são preferidos.


SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;

Otimizar a alocação de recursos

Monitore a utilização da CPU e ajuste o número de vCPUs se for consistentemente alto e se seu aplicativo se beneficiar de consultas paralelas. Verifique se há memória adequada disponível para operações paralelas.

  • Use as métricas do Performance Insights para determinar se o sistema está limitado pela CPU.

  • Cada operador paralelo usa o seu próprio work_mem. Verifique se o uso total da memória está dentro dos limites da instância.

As consultas paralelas podem consumir substancialmente mais recursos do que as consultas não paralelas, porque cada processo de operador é completamente separado que tem aproximadamente o mesmo impacto no sistema que uma sessão de usuário adicional. Isso deve ser levado em consideração ao escolher um valor para essa configuração, bem como ao definir outras configurações que controlam a utilização de recursos, como work_mem. Para obter mais informações, consulte a Documentação do PostgreSQL. Limites de recursos, como work_mem, são aplicados individualmente a cada operador, o que significa que a utilização total pode ser muito maior em todos os processos do que normalmente seria em qualquer processo único.

Aumente as vCPUs ou ajuste os parâmetros de memória se sua workload estiver altamente paralelizada.

Investigar o gerenciamento de conexão

Se estiver experimentando esgotamento de conexões, revise as estratégias de pool de conexões do aplicativo. Implemente o pool de conexões no nível do aplicativo, se ainda não estiver em uso.

Revisar e otimizar as operações de manutenção

Coordene a criação de índices e outras tarefas de manutenção para evitar a contenção de recursos. Agende essas operações fora do horário de pico. Evite agendar manutenções pesadas (por exemplo, construções paralelas de índices) durante períodos de alta carga de consultas do usuário. Essas operações podem consumir workers paralelos e impactar o desempenho de consultas regulares.

Utilize o gerenciamento de planos de consultas (QPM)

No Aurora PostgreSQL, o atributo de gerenciamento de planos de consulta (QPM) foi projetado para garantir a adaptabilidade e a estabilidade do plano, independentemente das alterações no ambiente de banco de dados que poderiam causar a regressão do plano de consulta. Para obter mais informações, consulte Visão geral do gerenciamento de planos de consulta do Aurora PostgreSQL. O QPM fornece algum controle sobre o otimizador. Revise os planos aprovados no QPM para garantir que estejam alinhados com as configurações atuais de paralelismo. Atualize ou remova planos desatualizados que possam estar forçando uma execução paralela subótima.

Você também pode corrigir os planos usando pg_hint_plan. Para obter mais informações, consulte Corrigir planos usando pg_hint_plan. Você pode usar a dica chamada Parallel para forçar a execução paralela. Para obter mais informações, consulte Dicas para planos paralelos.