Início / dba / Perguntas / 98087
Accepted
Andomar
Asked: 2015-04-17 12:42:42 +0800 CST

Hickups de desempenho após a atualização do Postgres 9.4

  • 772

Depois de atualizar nosso banco de dados de 9.3.5 para 9.4.1 ontem à noite, o servidor sofre picos de CPU elevados. A atualização foi feita com pg_dump. Portanto, o banco de dados foi convertido para SQL e depois importado para 9.4.

Durante os picos de CPU, há muitas dessas mensagens nos logs:

process X still waiting for ExclusiveLock on extension of relation Y of database Z 
after 1036.234 ms

E:

process X acquired ExclusiveLock on extension of relation Y of database Z
after 2788.050 ms

O que parece suspeito é que às vezes existem várias mensagens "adquiridas" para o mesmo número de relação exatamente no mesmo milissegundo.

Por que o Postgres aumentaria uma tabela duas vezes no mesmo milissegundo? Poderia ser um índice com um fator de preenchimento alto?

Qualquer sugestão sobre como abordar esse problema é bem-vinda.

PS Eu também fiz esta pergunta na lista de discussão do Postgres , se não estiver bem, me avise.

postgresql locking

2 respostas

  1. Best Answer

    O problema tinha a ver com um recurso do kernel chamado Transparent Huge Pages (THP). Você pode diagnosticar isso com perf top:

     59.73%       postmaster  [kernel.kallsyms]      [k] compaction_alloc
  1.31%       postmaster  [kernel.kallsyms]      [k] _spin_lock
  0.94%       postmaster  [kernel.kallsyms]      [k] __reset_isolation_suitable
  0.78%       postmaster  [kernel.kallsyms]      [k] compact_zone
  0.67%       postmaster  [kernel.kallsyms]      [k] get_pageblock_flags_group
  0.64%       postmaster  [kernel.kallsyms]      [k] copy_page_c
  0.48%           :13410  [kernel.kallsyms]      [k] compaction_alloc
  0.45%           :13465  [kernel.kallsyms]      [k] compaction_alloc
  0.45%       postmaster  [kernel.kallsyms]      [k] clear_page_c
  0.44%       postmaster  postgres               [.] hash_search_with_hash_value
  0.41%           :13324  [kernel.kallsyms]      [k] compaction_alloc
  0.40%           :13561  [kernel.kallsyms]      [k] compaction_alloc

    A compaction_allocfunção aponta para um problema. Você pode desativar o THP com:

    echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

    As versões do Postgres anteriores a 9.4 não solicitam especificamente páginas enormes, mas podem ser forçadas com always.

    Aqui está um link para o RedHat desencorajando o THP para cargas de trabalho de banco de dados.

    • 4

  2. Um ciclo de dump-restore remove todas as tuplas inchadas e mortas de suas tabelas e restaura com o tamanho mínimo possível - exceto se você tiver uma fillfactorconfiguração abaixo de 100 que reserve algum espaço de manobra por página de dados.

    Imediatamente após a migração, você obtém muito mais "extensões" (páginas adicionadas no final físico da tabela (o arquivo no disco).

    A solução pró-ativa seria definir fillfactorabaixo de 100 em tabelas com muitas atualizações aleatórias. Você pode fazer isso no dump antes de restaurar novamente. Como você já concluiu a migração, pode esperar a poeira baixar. Normalmente, as extensões se tornam menos frequentes enquanto o espaço de manobra é reintroduzido com versões de linhas mortas em suas tabelas atualizadas.

    Para tabelas com muitas atualizações aleatórias, pode ser uma boa ideia definir FILLFACTORabaixo de 100 em qualquer caso. Aplica-se a índices btree de maneira semelhante. Mas o espaço reservado só é adicionado às páginas de dados existentes com um VACUUM FULLou CLUSTER(ou um ciclo de despejo-restauração).

    Mais sobre FILLFACTOR, atualizações e VACUUM:

    • 2

relate perguntas