# IPC:ProcArrayGroupUpdate
<a name="apg-rpg-ipcprocarraygroup"></a>

O evento `IPC:ProcArrayGroupUpdate` ocorre quando uma sessão está aguardando o líder do grupo atualizar o status da transação ao final dessa operação. Embora o PostgreSQL geralmente associe eventos de espera do tipo IPC a operações de consulta paralela, esse evento de espera determinado não é específico de consultas paralelas.

**Topics**
+ [Versões compatíveis do mecanismo](#apg-rpg-ipcprocarraygroup.supported)
+ [Contexto](#apg-rpg-ipcprocarraygroup.context)
+ [Possíveis causas do maior número de esperas](#apg-rpg-ipcprocarraygroup.causes)
+ [Ações](#apg-rpg-ipcprocarraygroup.actions)

## Versões compatíveis do mecanismo
<a name="apg-rpg-ipcprocarraygroup.supported"></a>

As informações sobre esse evento de espera são aceitas em todas as versões do RDS para PostgreSQL.

## Contexto
<a name="apg-rpg-ipcprocarraygroup.context"></a>

**Noções básicas sobre a matriz do processo**: a matriz do processo (proc) é uma estrutura de memória compartilhada no PostgreSQL. Ela contém informações sobre todos os processos em execução, incluindo detalhes da transação. Durante a conclusão da transação (`COMMIT` ou `ROLLBACK`), o ProcArray precisa ser atualizado para refletir a alteração e limpar o ID da transação da matriz. A sessão que tenta concluir sua transação deve adquirir um bloqueio exclusivo no ProcArray. Isso impede que outros processos tenham bloqueios compartilhados ou exclusivos.

**Mecanismo de atualização de grupo**: ao executar um COMMIT ou ROLLBACK, se um processo de backend não conseguir recuperar um ProcArrayLock no modo exclusivo, ele atualizará um campo especial chamado ProcArrayGroupMember. Isso adiciona a transação à lista de sessões que pretendem terminar. Esse processo de backend então é suspenso, e o tempo de suspensão é instrumentado como o evento de espera ProcArrayGroupUpdate. O primeiro processo no ProcArray com o procArrayGroupMember, conhecido como processo líder, adquire o ProcArrayLock no modo exclusivo. Depois, ele limpa a lista de processos que aguardam a limpeza do transactionID do grupo. Quando isso é concluído, o líder libera o ProcArrayLock e, depois, ativa todos os processos dessa lista, notificando-os de que a transação foi concluída.

## Possíveis causas do maior número de esperas
<a name="apg-rpg-ipcprocarraygroup.causes"></a>

Quanto mais processos estiverem em execução, mais tempo um líder manterá um procArrayLock no modo exclusivo. Consequentemente, quanto mais transações de gravação ocorrerem, maior a chance de entrarem em um cenário de atualização em grupo, causando um possível acúmulo de processos aguardando o evento de espera `ProcArrayGroupUpdate`. Na visualização Top SQL do Database Insights, você verá que COMMIT é a declaração com a maior parte desse evento de espera. Isso é esperado, mas exigirá uma investigação mais profunda do SQL de gravação específico que está sendo executado para determinar qual ação apropriada realizar.

## Ações
<a name="apg-rpg-ipcprocarraygroup.actions"></a>

Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Identifique eventos `IPC:ProcArrayGroupUpdate` utilizando o Insights de Performance do Amazon RDS ou consultando a visualização `pg_stat_activity` do sistema PostgreSQL.

**Topics**
+ [Monitorar operações de confirmação e reversão de transações](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [Reduzir a simultaneidade](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [Implementar o agrupamento de conexões](#apg-rpg-ipcprocarraygroup.actions.pooling)
+ [Usar um armazenamento mais rápido](#apg-rpg-ipcprocarraygroup.actions.storage)

### Monitorar operações de confirmação e reversão de transações
<a name="apg-rpg-ipcprocarraygroup.actions.monitor"></a>

**Monitorar confirmações e reversões**: um número maior de confirmações e reversões pode aumentar a pressão sobre o ProcArray. Por exemplo, se uma instrução SQL começar a falhar devido ao aumento das violações de chaves duplicadas, você poderá observar um aumento nas reversões, o que pode aumentar a contenção do ProcArray e o inchaço da tabela.

O Amazon RDS Database Insights fornece as métricas `xact_commit` e `xact_rollback` do PostgreSQL e relata o número de confirmações e reversões por segundo.

### Reduzir a simultaneidade
<a name="apg-rpg-ipcprocarraygroup.actions.concurrency"></a>

**Transações em lote**: sempre que possível, agrupe operações em transações únicas para reduzir as operações de confirmação/reversão.

**Limitar a simultaneidade**: reduza o número de transações ativas simultaneamente para aliviar a contenção de bloqueios no ProcArray. Embora isso exija alguns testes, reduzir o número total de conexões simultâneas pode reduzir a contenção e manter o throughput.

### Implementar o agrupamento de conexões
<a name="apg-rpg-ipcprocarraygroup.actions.pooling"></a>

**Soluções de agrupamento de conexões**: use o grupo de conexões para gerenciar conexões de banco de dados com eficiência, reduzindo o número total de backends e, portanto, a workload no ProcArray. Embora isso exija alguns testes, reduzir o número total de conexões simultâneas pode reduzir a contenção e manter o throughput.

**Reduzir os surtos de conexão**: da mesma forma, um padrão de criação e encerramento frequentes de conexões causa pressão adicional no ProcArray. Ao reduzir esse padrão, a contenção geral é reduzida.

### Usar um armazenamento mais rápido
<a name="apg-rpg-ipcprocarraygroup.actions.storage"></a>

**Volume de log dedicado**: se o evento de espera `IPC:ProcArrayGroupUpdate` for acompanhado por eventos de alta espera `IO:WALWrite`, a configuração de um volume de logs dedicado poderá reduzir o gargalo de gravação no WAL. Por sua vez, isso melhora a performance das confirmações.

Para acessar mais informações, consulte [Volume de logs dedicado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.dlv.html).