LWLock:lock_manager
Esse evento ocorre quando o mecanismo Aurora PostgreSQL mantém a área de memória do bloqueio compartilhado para alocar, verificar e desalocar um bloqueio nos casos em que um bloqueio de caminho rápido não é possível.
Versões compatíveis do mecanismo
As informações sobre eventos de espera são relevantes para o Aurora PostgreSQL versão 9.6 e versões superiores.
Contexto
Quando você emite uma instrução SQL, o Aurora PostgreSQL registra bloqueios para proteger a estrutura, os dados e a integridade do banco de dados durante operações simultâneas. O mecanismo pode atingir esse objetivo utilizando um bloqueio de caminho rápido ou um bloqueio de caminho que não é rápido. Um bloqueio de caminho que não é rápido é mais caro e gera mais sobrecarga do que um bloqueio de caminho rápido.
Bloqueio de caminho rápido
Para reduzir a sobrecarga de bloqueios que são retirados e liberados com frequência, mas que raramente entram em conflito, os processos de backend podem utilizar o bloqueio de caminho rápido. O banco de dados usa esse mecanismo para bloqueios que atendem aos seguintes critérios:
-
Usam o método de bloqueio DEFAULT.
-
Representam um bloqueio em uma relação de banco de dados em vez de uma relação compartilhada.
-
São bloqueios fracos que provavelmente não entrarão em conflito.
-
O mecanismo é capaz de verificar rapidamente se nenhum bloqueio conflitante pode existir.
O mecanismo não pode utilizar o bloqueio rápido de caminho quando uma das seguintes condições é verdadeira:
-
O bloqueio não atende aos critérios anteriores.
-
Não há mais slots disponíveis para o processo de backend.
Para obter mais informações sobre o bloqueio de caminho rápido, consulte o tópico sobre caminho rápido
Exemplo de um problema de escalabilidade para o gerenciador de bloqueios
Neste exemplo, uma tabela chamada purchases armazena cinco anos de dados, particionados por dia. Cada partição possui dois índices. A seguinte sequência de eventos ocorre:
-
Você consulta muitos dias de dados, o que exige que o banco de dados leia várias partições.
-
O banco de dados cria uma entrada de bloqueio para cada partição. Se os índices de partição fizerem parte do caminho de acesso do otimizador, o banco de dados também criará uma entrada de bloqueio para eles.
-
Quando o número de entradas de bloqueios solicitadas para o mesmo processo de backend for maior que 16, que é o valor de
FP_LOCK_SLOTS_PER_BACKEND, o gerenciador de bloqueio usará o método de bloqueio de caminho não rápido.
Aplicações modernas podem ter centenas de sessões. Se sessões simultâneas estiverem consultando o pai sem a devida limpeza da partição, o banco de dados poderá criar centenas ou até milhares de bloqueios de caminho não rápidos. Em geral, quando essa simultaneidade é maior que o número de vCPUs, o evento de espera LWLock:lock_manager é exibido.
nota
O evento de espera LWLock:lock_manager não está relacionado ao número de partições ou índices em um esquema de banco de dados e sim ao número de bloqueios de caminho não rápidos que o banco de dados deve controlar.
Possíveis causas do maior número de esperas
Quando o evento de espera LWLock:lock_manager ocorre mais do que o normal, possivelmente indicando um problema de performance, as causas mais prováveis de picos súbitos são:
-
Sessões ativas simultâneas estão executando consultas que não utilizam bloqueios de caminho rápido. Essas sessões também excedem a vCPU máxima.
-
Um número elevado de sessões ativas simultâneas está acessando uma tabela fortemente particionada. Cada partição possui vários índices.
-
O banco de dados está passando por uma tempestade de conexões. Por padrão, algumas aplicações e softwares de grupo de conexões criam mais conexões quando o banco de dados está lento. Essa prática piora o problema. Ajuste o software do grupo de conexões para que tempestades de conexões não ocorram.
-
Um número elevado de sessões consulta uma tabela pai sem separar partições.
-
Um comando de linguagem de definição de dados (DDL), linguagem de manipulação de dados (DML) ou manutenção bloqueia exclusivamente uma relação ocupada ou tuplas que são frequentemente acessadas ou modificadas.
Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
Tópicos
Usar a limpeza de partição
Limpeza de partição é uma estratégia de otimização de consultas que exclui partições desnecessárias das varreduras de tabelas, melhorando assim a performance. Por padrão, a remoção de partição está ativada. Se ela estiver desativada, ative-a da seguinte maneira.
SET enable_partition_pruning = on;
As consultas podem tirar proveito da limpeza de partição quando suas cláusula WHERE contêm a coluna utilizada para o particionamento. Para obter mais informações, consulte o tópico sobre Limpeza de partição
Remover índices desnecessários
Seu banco de dados pode conter índices não utilizados ou raramente utilizados. Se esse for o caso, considere excluí-los. Realize um dos procedimentos a seguir:
-
Saiba mais sobre como encontrar índices desnecessários lendo o tópico sobre Índices não utilizados
na wiki do PostgreSQL. -
Execute o PG Collector. Esse script SQL reúne informações do banco de dados e as apresenta em um relatório HTML consolidado. Confira a seção “Índices não utilizados”. Para obter mais informações, consulte pg-collector
no Repositório AWS Labs GitHub.
Ajustar suas consultas para bloqueio de caminho rápido
Para descobrir se as suas consultas usam o bloqueio de caminho rápido, consulte a coluna fastpath na tabela pg_locks. Se as suas consultas não estiverem utilizando o bloqueio de caminho rápido, tente reduzir o número de relações por consulta para menos de 16.
Fazer ajustes com base em eventos de espera
Se LWLock:lock_manager for o primeiro ou o segundo na lista de principais esperas, verifique se os seguintes eventos de espera também aparecem na lista:
-
Lock:Relation -
Lock:transactionid -
Lock:tuple
Se os eventos anteriores aparecerem em posição elevada na lista, considere ajustar esses eventos de espera primeiro. Esses eventos podem ser um fator impulsionador para LWLock:lock_manager.
Reduzir gargalos de hardware
É possível que haja um gargalo de hardware, como falta de CPU ou uso máximo da largura de banda do Amazon EBS. Nesses casos, considere reduzir gargalos de hardware. Considere as ações a seguir:
-
Aumente a escala da sua classe de instância na vertical.
-
Otimize consultas que consomem grandes quantidades de CPU e memória.
-
Altere a lógica da aplicação.
-
Arquive os dados.
Para obter mais informações sobre CPU, memória e largura de banda da rede do EBS, consulte Tipos de instâncias do Amazon RDS
Usar um agrupador de conexões
Se o número total de conexões ativas exceder o máximo de vCPU, mais processos do SO exigirão CPU do que o tipo de instância pode suportar. Nesse caso, considere utilizar ou ajustar um grupo de conexões. Para obter mais informações sobre as vCPUs para o seu tipo de instância, consulte o tópico sobre Tipos de instância do Amazon RDS
Para obter mais informações sobre agrupamento de conexões, consulte os seguintes recursos:
-
Grupos conexões e fontes de dados
, na Documentação do PostgreSQL
Fazer upgrade da versão do Aurora PostgreSQL
Se a versão atual do Aurora PostgreSQL for menor que 12, atualize para a versão 12 ou superior. As versões 12 e 13 do PostgreSQL possuem um mecanismo de partição aprimorado. Para obter mais informações sobre a versão 12, consulte Notas de release do PostgreSQL 12.0
