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.

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

Tópicos

• Realizar a operação vacuum freeze nas tabelas com este evento de espera
• Aumentar a frequência da limpeza automática das tabelas com esse evento de espera
• Aumentar os parâmetros de memória
• Reduzir transações de longa execução
• Ações de longo prazo

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.

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

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

Aumentar os parâmetros de memória

É possível definir os parâmetros a seguir em nível de cluster para que todas as instâncias do cluster permaneçam consistentes. Isso ajuda a reduzir os eventos de espera na workload. Recomendamos não definir esses valores tão altos a ponto de ficar sem memória.

• multixact_offsets_cache_size como 128

• multixact_members_cache_size como 256

É necessário reinicializar a instância para que a alteração do parâmetro tenha efeito. Com esses parâmetros, é possível usar mais RAM da instância para armazenar a estrutura multixact na memória antes de transferir para o disco.

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 ter mais informações, consulte O banco de dados está inativo há muito tempo na conexão da transação. 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.

• Reduza o uso de pontos de salvamento nas transações.