Centro de Conhecimento DevOps
Centro de Conhecimento DevOps

Como Identificar e Resolver Deadlocks e Contenção de Bloqueio no PostgreSQL

Domine a contenção de bloqueio e os deadlocks do PostgreSQL. Aprenda a usar `pg_locks` para identificar sessões bloqueadoras, analisar cenários comuns de deadlock e descobrir técnicas práticas como ordenação consistente de transações e consultas otimizadas para prevenir e resolver esses problemas críticos do banco de dados. Garanta operações do PostgreSQL mais suaves e eficientes.

53 visualizações

Entendendo e Resolvendo Deadlocks e Contenção de Bloqueio no PostgreSQL

O PostgreSQL, um banco de dados relacional de código aberto poderoso e amplamente utilizado, oferece mecanismos robustos de controle de concorrência para permitir que vários usuários e aplicativos acessem e modifiquem dados simultaneamente. No entanto, quando essas operações concorrentes interagem de maneiras complexas, isso pode levar a situações como contenção de bloqueio e, em casos mais graves, deadlocks (impasse). Entender como os bloqueios funcionam no PostgreSQL, identificar as causas raízes da contenção e implementar estratégias de resolução eficazes são cruciais para manter o desempenho e a disponibilidade do banco de dados.

Este artigo irá guiá-lo pelas complexidades do bloqueio no PostgreSQL. Exploraremos os diferentes tipos de bloqueios, como alavancar a visão do sistema pg_locks para diagnosticar problemas de bloqueio, identificar sessões de bloqueio, analisar cenários comuns de deadlock e, o mais importante, discutir técnicas práticas para prevenir e resolver esses gargalos de desempenho. Ao dominar esses conceitos, você pode garantir operações mais suaves e eficientes em seu ambiente PostgreSQL.

Noções Básicas de Bloqueio no PostgreSQL

O PostgreSQL utiliza um mecanismo de bloqueio sofisticado para gerenciar o acesso concorrente a objetos do banco de dados, como tabelas, linhas e até mesmo colunas específicas. O objetivo principal é garantir a integridade dos dados, impedindo operações conflitantes. No entanto, esse mecanismo também pode ser uma fonte de problemas de desempenho se não for gerenciado com cuidado.

Tipos de Bloqueios

O PostgreSQL utiliza vários níveis de bloqueio, cada um oferecendo um grau diferente de proteção. Compreender isso é fundamental para diagnosticar problemas:

  • Access Exclusive Lock (Bloqueio de Acesso Exclusivo): Acesso exclusivo a um recurso. Nenhuma outra transação pode adquirir qualquer bloqueio no recurso. Este é o bloqueio mais restritivo.
  • Exclusive Lock (Bloqueio Exclusivo): Apenas uma transação pode manter este bloqueio. Outras transações podem ler o recurso, mas não podem modificá-lo.
  • Share Update Exclusive Lock (Bloqueio de Compartilhamento de Atualização Exclusiva): Permite que outros leiam, mas não escrevam, e impede que outros adquiram certos outros bloqueios.
  • Share Row Exclusive Lock (Bloqueio de Linha Exclusiva de Compartilhamento): Permite que várias transações mantenham bloqueios Share Row Exclusive ou bloqueios Share, mas apenas uma transação pode manter um bloqueio Exclusive, Share Update Exclusive ou Row Exclusive.
  • Share Lock (Bloqueio de Compartilhamento): Permite que várias transações mantenham bloqueios Share concorrentemente. No entanto, bloqueia qualquer transação que tente adquirir um bloqueio Exclusive, Access Exclusive ou Share Update Exclusive.
  • Row Exclusive Lock (Bloqueio Exclusivo de Linha): Permite que várias transações mantenham bloqueios Row Exclusive concorrentemente. Impede que transações adquiram bloqueios Exclusive, Access Exclusive ou Share Update Exclusive. Este é um tipo de bloqueio comum para operações UPDATE e DELETE.
  • Exclusive Lock (Bloqueio Exclusivo): Concede acesso exclusivo a uma transação para uma linha específica. Outras transações podem ler a linha, mas não podem adquirir nenhum bloqueio de nível de linha nela.
  • Access Exclusive Lock (Bloqueio de Acesso Exclusivo): O bloqueio mais restritivo, impedindo que qualquer outra transação acesse o recurso em qualquer nível.

Modos de Bloqueio

Os modos de bloqueio indicam o tipo de acesso que uma transação requer. Eles são frequentemente representados por nomes como RowExclusiveLock, ShareLock, ExclusiveLock, etc.

Identificando Contenção de Bloqueio e Sessões de Bloqueio

A contenção de bloqueio ocorre quando várias transações estão esperando por bloqueios mantidos por outras transações. Isso pode diminuir significativamente o desempenho do seu aplicativo. A visão do sistema pg_locks é sua principal ferramenta para diagnosticar esses problemas.

Usando pg_locks

A visão pg_locks fornece informações sobre todos os bloqueios ativos no sistema de banco de dados. É inestimável para entender quais sessões estão mantendo bloqueios e quais estão esperando.

Aqui está uma consulta comum para identificar sessões de bloqueio:

SELECT
    blocked_locks.pid AS blocked_pid,
    blocked_activity.usename AS blocked_user,
    blocked_locks.locktype AS blocked_locktype,
    blocked_locks.virtualtransaction AS blocked_vtx,
    blocked_locks.mode AS blocked_mode,
    blocked_activity.query AS blocked_statement,
    blocking_locks.pid AS blocking_pid,
    blocking_activity.usename AS blocking_user,
    blocking_locks.locktype AS blocking_locktype,
    blocking_locks.virtualtransaction AS blocking_vtx,
    blocking_locks.mode AS blocking_mode,
    blocking_activity.query AS blocking_statement
FROM
    pg_catalog.pg_locks blocked_locks
JOIN
    pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN
    pg_catalog.pg_locks blocking_locks
ON
    blocking_locks.locktype = blocked_locks.locktype AND
    blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE AND
    blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation AND
    blocking_locks.offset IS NOT DISTINCT FROM blocked_locks.offset AND
    blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page AND
    blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
JOIN
    pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE
    NOT blocked_locks.granted
    AND blocking_locks.pid != blocked_locks.pid;

Explicação da consulta:

  • Nós unimos pg_locks com pg_stat_activity duas vezes: uma para o processo bloqueado e outra para o processo de bloqueio.
  • A cláusula WHERE NOT blocked_locks.granted filtra por bloqueios pelos quais se está atualmente esperando.
  • O blocking_locks.pid != blocked_locks.pid garante que não relatemos uma sessão bloqueando a si mesma.
  • As condições de junção em pg_locks correspondem a bloqueios no mesmo recurso.

Interpretando a Saída

  • blocked_pid / blocking_pid: Os IDs de processo (PIDs) das sessões envolvidas.
  • blocked_user / blocking_user: Os usuários associados a esses PIDs.
  • blocked_statement / blocking_statement: As consultas SQL que estão atualmente em execução ou aguardando.
  • blocked_mode / blocking_mode: Os modos de bloqueio solicitados e mantidos.

Se esta consulta retornar linhas, você tem contenção de bloqueio. O blocking_pid está mantendo um bloqueio pelo qual o blocked_pid está esperando.

Entendendo e Resolvendo Deadlocks

Um deadlock (impasse) ocorre quando duas ou mais transações estão cada uma esperando por um bloqueio mantido por outra transação no ciclo, criando uma dependência circular que nenhuma delas pode resolver sozinha. O PostgreSQL detecta deadlocks e os resolve automaticamente abortando uma das transações, tipicamente aquela que está causando o deadlock e realizou o menor trabalho.

Cenários Comuns de Deadlock

  1. Duas transações atualizando linhas diferentes em tabelas diferentes em ordem inversa:

    • Transação A: Atualiza a linha X na Tabela 1, depois tenta atualizar a linha Y na Tabela 2.
    • Transação B: Atualiza a linha Y na Tabela 2, depois tenta atualizar a linha X na Tabela 1.
      Se a Transação A bloquear a linha X e a Transação B bloquear a linha Y, elas entrarão em deadlock ao tentar adquirir o bloqueio mantido pela outra.

  2. UPDATE seguido por SELECT ... FOR UPDATE:

    • Transação A: Atualiza uma linha.
    • Transação B: Executa SELECT ... FOR UPDATE na mesma linha.
      Se o UPDATE ainda estiver mantendo um bloqueio de exclusividade de linha quando o SELECT FOR UPDATE tentar adquirir um bloqueio de compartilhamento, e outras dependências existirem, um deadlock pode ocorrer.

Detectando Deadlocks

O PostgreSQL registra informações de deadlock em seu log do servidor. Você normalmente verá mensagens como:

ERROR:  deadlock detected
DETAIL:  Process 1234 waits for ShareLock on transaction 5678; blocked by process 5679.
Process 5679 waits for ExclusiveLock on tuple (0,1) of relation 12345; blocked by process 1234.
HINT:  See server log for detail.

O PostgreSQL escolhe automaticamente um processo vítima para abortar. Você também pode usar pg_stat_activity para ver as consultas envolvidas no momento da detecção.

Resolvendo Deadlocks

Quando um deadlock é detectado e o PostgreSQL o resolve abortando uma transação:

  1. Identifique a Vítima: Verifique os logs do PostgreSQL em busca da mensagem deadlock detected. Ela especificará qual processo foi abortado.
  2. Repita a Transação Abortada: O aplicativo que recebe o erro de deadlock deve ser projetado para capturar esse erro específico (por exemplo, código de erro deadlock_detected) e repetir a transação. Esta é a maneira mais comum e eficaz de lidar com deadlocks da perspectiva do aplicativo.
  3. Analise a Causa: A chave para a resolução é prevenir deadlocks futuros. Isso envolve entender por que o deadlock ocorreu (conforme descrito nos cenários comuns) e ajustar a lógica do aplicativo ou o design do banco de dados.

Técnicas para Prevenir Contenção de Bloqueio e Deadlocks

A prevenção é sempre melhor que a cura. Implementar estratégias para minimizar a contenção de bloqueio e evitar situações de deadlock é crucial para um banco de dados PostgreSQL de alto desempenho.

1. Ordenação Consistente de Transações

  • Regra: Sempre acesse e modifique recursos (tabelas, linhas) na mesma ordem em todas as transações. Se várias transações precisarem atualizar a TableA e a TableB, certifique-se de que elas sempre atualizem a TableA antes da TableB, ou vice-versa, de forma consistente.
  • Exemplo: Se uma transação precisar atualizar registros em users e orders, sempre execute as operações em users primeiro, depois em orders. Evite cenários em que uma transação atualiza users e depois orders, enquanto outra atualiza orders e depois users.

2. Minimizando a Duração da Transação

  • Regra: Mantenha as transações o mais curtas possível. Quanto mais tempo uma transação estiver aberta, mais bloqueios ela manterá, aumentando a chance de contenção.
  • Ação: Execute apenas as operações de banco de dados necessárias dentro de uma transação. Mova trabalhos não relacionados ao banco de dados (por exemplo, chamadas de API externas, cálculos complexos não dependentes do estado da transação) para fora do limite da transação.

3. Usar Níveis de Isolamento Apropriados

  • Regra: Entenda e escolha o nível de isolamento de transação correto. O PostgreSQL oferece:
    • READ UNCOMMITTED (simulado por READ COMMITTED no PostgreSQL)
    • READ COMMITTED (padrão)
    • REPEATABLE READ
    • SERIALIZABLE
  • Ação: O padrão READ COMMITTED oferece bom desempenho enquanto previne leituras sujas. REPEATABLE READ e SERIALIZABLE oferecem consistência mais forte, mas podem levar a mais erros de serialization_failure (que são essencialmente deadlocks para isolamento de snapshot) e potencialmente mais contenção de bloqueio. Use-os apenas quando absolutamente necessário.

4. Otimizar Consultas e Índices

  • Regra: Consultas lentas mantêm bloqueios por mais tempo. Garanta que suas consultas sejam eficientes e bem indexadas.
  • Ação: Use EXPLAIN ANALYZE para identificar consultas lentas. Adicione índices apropriados para acelerar a recuperação de dados, especialmente para cláusulas WHERE e condições JOIN.

5. Usar SELECT ... FOR UPDATE com Moderação

  • Regra: SELECT ... FOR UPDATE bloqueia linhas durante toda a duração da transação. Isso é poderoso para prevenir condições de corrida, mas também pode ser uma grande fonte de contenção.
  • Ação: Use-o apenas quando você realmente precisar bloquear linhas para evitar que elas sejam modificadas por outras transações antes que sua transação conclua seu trabalho. Considere se bloqueios de aconselhamento (advisory locks) podem ser mais adequados para certos cenários.

6. Bloqueios de Aconselhamento (Advisory Locks)

  • Regra: Para bloqueio em nível de aplicativo ou necessidades de sincronização mais complexas que não se mapeiam diretamente para bloqueios de objetos de banco de dados, os bloqueios de aconselhamento do PostgreSQL podem ser uma ferramenta poderosa.
  • Ação: Use funções como pg_advisory_lock(), pg_advisory_lock_shared() e pg_advisory_unlock() para implementar mecanismos de bloqueio personalizados. Esses bloqueios não são detectados automaticamente pelo mecanismo de detecção de deadlock, portanto, a lógica do aplicativo deve gerenciá-los com cuidado.

7. Agrupamento de Operações (Batching)

  • Regra: Em vez de emitir muitas instruções UPDATE ou DELETE individuais, considere agrupá-las em uma única instrução ou usar COPY para carregamento/atualização em lote, sempre que possível.
  • Ação: Uma única instrução UPDATE pode adquirir bloqueios de forma mais eficiente do que um loop de UPDATEs individuais. Analise o comportamento de bloqueio de suas operações em lote.

Conclusão

A contenção de bloqueio e os deadlocks são desafios comuns em ambientes de banco de dados de alta concorrência. Ao entender os conceitos fundamentais de bloqueio no PostgreSQL, utilizando ferramentas como pg_locks e pg_stat_activity para diagnosticar problemas e implementando estratégias preventivas como ordenação consistente de transações, minimização da duração da transação e otimização de consultas, você pode melhorar significativamente a estabilidade e o desempenho do seu banco de dados PostgreSQL. Lembre-se de que um tratamento de erros robusto em seu aplicativo, especialmente para repetir transações em deadlock, também é uma parte crítica do gerenciamento eficaz dessas situações.