# LWLock:MultiXact
Os eventos de espera `LWLock:MultiXactMemberBuffer`, `LWLock:MultiXactOffsetBuffer`, `LWLock:MultiXactMemberSLRU` e `LWLock:MultiXactOffsetSLRU` indicam que uma sessão está aguardando para recuperar uma lista de transações que modificam a mesma linha em uma tabela específica.
+ `LWLock:MultiXactMemberBuffer`: um processo está aguardando a E/S em um buffer utilizado com menos frequência (SLRU) para um membro multixact.
+ `LWLock:MultiXactMemberSLRU`: um processo está aguardando para acessar o cache utilizado com menos frequência (SLRU) para um membro multixact.
+ `LWLock:MultiXactOffsetBuffer`: um processo está aguardando a E/S em um buffer utilizado com menos frequência (SLRU) para um desvio multixact.
+ `LWLock:MultiXactOffsetSLRU`: um processo está aguardando para acessar o cache utilizado com menos frequência (SLRU) para um desvio multixact.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.xactsync.context.supported)
+ [Contexto](#apg-waits.lwlockmultixact.context)
+ [Possíveis causas do maior número de esperas](#apg-waits.lwlockmultixact.causes)
+ [Ações](#apg-waits.lwlockmultixact.actions)
## 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
*Multixact* é uma estrutura de dados que armazena uma lista de IDs de transação (XIDs) que modificam a mesma linha da tabela. Quando uma única transação faz referência a uma linha em uma tabela, o ID da transação é armazenado na linha de cabeçalho da tabela. Quando várias transações fazem referência à mesma linha em uma tabela, a lista de IDs de transação é armazenada na estrutura de dados multixact. Os eventos de espera multixact indicam que uma sessão está recuperando da estrutura de dados a lista de transações que se referem a uma determinada linha em uma tabela.
## Possíveis causas do maior número de esperas
Estas são três causas comuns para uso do multixact:
+ **Subtransações de pontos de salvamento explícitos**: a criação explícita de um ponto de salvamento nas transações gera novas transações para a mesma linha. Por exemplo, usando `SELECT FOR UPDATE`, `SAVEPOINT` e, então `UPDATE`.
Alguns drivers, mapeamentos de objetos relacionais (ORMs) e camadas de abstração têm opções de configuração para envolver automaticamente todas as operações com pontos de salvamento. Isso pode gerar muitos eventos de espera multiexact em algumas workloads. A opção `autosave` do driver JDBC do PostgreSQL é um exemplo disso. Para obter mais informações, consulte [pgJDBC](https://jdbc.postgresql.org/) na documentação do JDBC do PostgreSQL. Outro exemplo é o driver ODBC do PostgreSQL e sua opção `protocol`. Para obter mais informações, consulte [psqlODBC Configuration Options](https://odbc.postgresql.org/docs/config.html) (Opções de configuração do psqlODBC) na documentação do driver ODBC do PostgreSQL.
+ **Subtransações de cláusulas EXCEPTION de PL/pgSQL**: cada cláusula `EXCEPTION` que você escreve em funções ou procedimentos de PL/pgSQL cria um `SAVEPOINT` interno.
+ **Chaves externas**: várias transações adquirem um bloqueio compartilhado no registro pai.
Quando uma determinada linha é incluída em uma operação de várias transações, o processamento da linha exige a recuperação de IDs de transação das listas `multixact`. Se as pesquisas não conseguirem obter o multixact do cache de memória, a estrutura de dados deverá ser lida da camada de armazenamento do Aurora. Essa E/S do armazenamento significa que as consultas de SQL podem demorar mais. As falhas no cache de memória podem começar a ocorrer com o uso intenso devido a um grande número de transações múltiplas. Todos esses fatores contribuem para o aumento desse evento de espera.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Algumas dessas ações podem ajudar na redução imediata dos eventos de espera. Porém, outras podem precisar de investigação e correção para escalar a workload.
**Topics**
+ [Realizar a operação vacuum freeze nas tabelas com este evento de espera](#apg-waits.lwlockmultixact.actions.vacuumfreeze)
+ [Aumentar a frequência da limpeza automática das tabelas com esse evento de espera](#apg-waits.lwlockmultixact.actions.autovacuum)
+ [Aumentar os parâmetros de memória](#apg-waits.lwlockmultixact.actions.memoryparam)
+ [Reduzir transações de longa execução](#apg-waits.lwlockmultixact.actions.longtransactions)
+ [Ações de longo prazo](#apg-waits.lwlockmultixact.actions.longactions)
### Realizar a operação vacuum freeze nas tabelas com este evento de espera
Se esse evento de espera aumentar repentinamente e afetar o ambiente de produção, você poderá usar qualquer um dos métodos temporários a seguir para reduzir a contagem.
+ Use *VACUUM FREEZE* na tabela ou na partição da tabela afetada para resolver o problema imediatamente. Para ter mais informações, consulte [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html).
+ Use a cláusula VACUUM (FREEZE, INDEX\_CLEANUP FALSE) para realizar uma limpeza rápida ignorando os índices. Para ter mais informações, consulte [Aspirar uma tabela o mais rápido possível](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
### Aumentar a frequência da limpeza automática das tabelas com esse evento de espera
Depois de verificar todas as tabelas em todos os bancos de dados, a operação VACUUM removerá multixacts, e os valores multixact mais antigos avançarão. Para ter mais informações, consulte [Multixacts e Wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND). Para reduzir ao mínimo os eventos de espera LWLock:MultiXact, é necessário executar a operação VACUUM sempre que necessário. Para fazer isso, garanta que o VACUUM no cluster de banco de dados do Aurora PostgreSQL esteja configurado de forma ideal.
Se o uso de VACUUM FREEZE na tabela ou na partição da tabela afetada resolver o problema do evento de espera, recomendamos usar um programador, como o `pg_cron`, para realizar o VACUUM em vez de ajustar o autovacuum na instância.
Para que o autovacuum ocorra com maior frequência, é possível reduzir o valor do parâmetro de armazenamento `autovacuum_multixact_freeze_max_age` na tabela afetada. Para ter mais informações, consulte [autovacuum\_multixact\_freeze\_max\_age](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MULTIXACT-FREEZE-MAX-AGE).
### Aumentar os parâmetros de memória
Você pode otimizar o uso da memória para caches multixact ajustando os seguintes parâmetros. Essas configurações controlam a quantidade de memória reservada para esses caches, o que pode ajudar a reduzir os eventos de espera multixact na workload. Recomendamos começar com os valores a seguir:
Para o Aurora PostgreSQL 17 e posterior:
+ `multixact_offset_buffers` = 128
+ `multixact_member_buffers` = 256
Para o Aurora PostgreSQL 16 e posterior:
+ `multixact_offsets_cache_size` = 128
+ `multixact_members_cache_size` = 256
**nota**
No Aurora PostgreSQL 17, os nomes dos parâmetros foram alterados de `multixact_offsets_cache_size` para `multixact_offset_buffers` e de `multixact_members_cache_size` para `multixact_member_buffers` para se alinharem à comunidade do PostgreSQL 17.
É possível definir esses parâmetros no nível do cluster para que todas as instâncias do cluster permaneçam consistentes. Recomendamos que você teste e ajuste os valores para melhor atender aos requisitos específicos da workload e à classe de instância. É necessário reinicializar a instância do gravador para que a alteração do parâmetro tenha efeito.
Os parâmetros são expressos em termos de entradas de cache multixact. Cada entrada de cache usa `8 KB` de memória. Para calcular a memória total reservada, multiplique o valor de cada parâmetro por `8 KB`. Por exemplo, se você definir um parâmetro como 128, o total de memória reservada será `128 * 8 KB = 1 MB`.
### Reduzir transações de longa execução
Transações de longa duração fazem com que o vácuo retenha as informações até que a transação seja confirmada ou até que a transação somente leitura seja fechada. Recomendamos que você monitore e gerencie transações de longa duração de maneira proativa. Para obter mais informações, consulte [O banco de dados está inativo há muito tempo na conexão da transação](PostgreSQL.Tuning_proactive_insights.md#proactive-insights.idle-txn). Tente modificar a aplicação para evitar ou minimizar o uso de transações de longa duração.
### Ações de longo prazo
Examine a workload para descobrir a causa do transbordamento de multixact. É necessário corrigir o problema para escalar a workload e reduzir o evento de espera.
+ É necessário analisar a DDL (linguagem de definição de dados) usada para criar tabelas. Verifique se as estruturas e os índices das tabelas estão bem projetados.
+ Quando as tabelas afetadas tiverem chaves externas, determine se elas são necessárias ou se há outra forma de aplicar a integridade referencial.
+ Quando uma tabela tem grandes índices não utilizados, isso pode fazer com que o autovacuum não se ajuste à workload e pode impedir a execução. Para evitar isso, verifique se há índices não utilizados e remova-os completamente. Para ter mais informações, consulte [Gerenciar o autovacuum com grandes índices](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html).
+ Reduza o uso de pontos de salvamento nas transações.