Lock:extend - Amazon Aurora
Versões compatíveis do mecanismoContextoPossíveis causas do maior número de esperasAções

Lock:extend

O evento Lock:extend ocorre quando um processo de backend está aguardando para bloquear uma relação com o objetivo de a estender, enquanto outro processo tem um bloqueio nessa relação para o mesmo objetivo.

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

O evento Lock:extend indica que um processo de backend está aguardando para estender uma relação na qual outro processo de backend mantém um bloqueio enquanto estende essa relação. Como apenas um processo por vez pode estender uma relação, o sistema gera um evento de espera Lock:extend. Operações INSERT, COPY e UPDATE podem gerar esse evento.

Possíveis causas do maior número de esperas

Quando o evento Lock:extend aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:

Surto de inserções simultâneas ou atualizações na mesma tabela

Pode haver um aumento no número de sessões simultâneas com consultas que inserem ou atualizam a mesma tabela.

Largura de banda da rede insuficiente

É possível que a largura de banda da rede na instância de banco de dados para as necessidades de comunicação de armazenamento da workload atual. Isso pode contribuir para a latência de armazenamento que causa um aumento em eventos Lock:extend.

Ações

Recomenda-se ações distintas, dependendo dos motivos do evento de espera.

Reduzir inserções e atualizações simultâneas para a mesma relação

Primeiro, determine se há um aumento nas métricas tup_inserted e tup_updated e um aumento acompanhante nesse evento de espera. Em caso afirmativo, verifique quais relações estão em alta disputa por operações de inserção e atualização. Para determinar isso, consulte a visualização pg_stat_all_tables para os valores nos campos n_tup_ins e n_tup_upd. Para obter mais informações sobre a visualização pg_stat_all_tables, consulte pg_stat_all_tables na documentação do PostgreSQL.

Para obter mais informações sobre bloqueio e consultas bloqueadas, consulte pg_stat_activity como no exemplo a seguir:

SELECT
    blocked.pid,
    blocked.usename,
    blocked.query,
    blocking.pid AS blocking_id,
    blocking.query AS blocking_query,
    blocking.wait_event AS blocking_wait_event,
    blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
 
   pid  | usename  |            query             | blocking_id |                         blocking_query                           | blocking_wait_event | blocking_wait_event_type
  ------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
   7143 |  myuser  | insert into tab1 values (1); |        4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend      | IO

Depois de identificar relações que contribuem para o aumento dos eventos Lock:extend, utilize as seguintes técnicas para reduzir a contenção:

  • Descubra se é possível utilizar o particionamento para reduzir a contenção para a mesma tabela. Separar tuplas inseridas ou atualizadas em partições diferentes pode reduzir a contenção. Para obter informações sobre particionamento, consulte Gerenciar partições do PostgreSQL com a extensão pg_partman.

  • Se o evento de espera for principalmente devido a atividades de atualização, reduza o valor do fator de preenchimento da relação. Isso pode reduzir as solicitações de novos bloqueios durante a atualização. O fator de preenchimento é um parâmetro de armazenamento de uma tabela que determina o espaço máximo para empacotar uma página de tabela. Ele é expresso como uma porcentagem do espaço total de uma página. Para obter mais informações sobre o parâmetro de fator de preenchimento, consulte CREATE TABLE na documentação do PostgreSQL.

    Importante

    É altamente recomendável testar seu sistema se você alterar o fator de preenchimento, pois isso pode afetar negativamente a performance dependendo da workload.

Aumentar a largura de banda da rede

Para ver se há um aumento na latência de gravação, verifique a métrica WriteLatency no CloudWatch. Se houver, use as métricas WriteThroughput e ReadThroughput do Amazon CloudWatch para monitorar o tráfego relacionado ao armazenamento no cluster de banco de dados. Essas métricas podem ajudar a determinar se a largura de banda da rede é suficiente para a atividade de armazenamento da sua workload.

Se a largura de banda da rede não suficiente, aumente-a. Se a sua instância de banco de dados estiver atingindo os limites de largura de banda da rede, a única maneira de aumentar a largura de banda será ampliar o tamanho da instância de banco de dados.

Para obter mais informações sobre métricas do CloudWatch, consulte Métricas do Amazon CloudWatch para o Amazon Aurora. Para obter informações sobre a performance de rede de cada classe de instância de banco de dados, consulte Especificações de hardware para classes de instância de banco de dados para o Aurora.