Início / dba / Perguntas / 35351
Accepted
ETL
Asked: 2013-02-25 17:15:20 +0800 CST

Acesso lento à tabela no postgresql apesar do vácuo

  • 772

Estou executando o PG 8.4

Eu tinha uma tabela com cerca de 20 mil registros. Qualquer consulta acessando esta tabela com mais de 1 registro (por exemplo, joins) seria muito, muito lenta. Mesmo uma contagem levaria cerca de 20 segundos.

As estatísticas mostraram 5 milhões de live_tuples.

Tentei vácuo, análise de vácuo e, no final, vácuo completo. Nada muda em termos de velocidade. E as estatísticas ainda mostravam a mesma coisa.

Acabei criando uma nova tabela, inseri todos os registros na nova tabela e derrubei/renomeei a antiga.

A nova mesa agora funciona muito rápido.

Alguma ideia de:

1) Qual teria sido o manejo mais correto? Estou procurando uma maneira melhor de fazer isso, pois um dos efeitos colaterais é que as exibições que apontavam para a tabela foram modificadas pela instrução "alter table rename to" e, sem o meu conhecimento, as exibições apontavam para o antigo mesa para 2 dias!

2) Por que isso aconteceria em primeiro lugar?

postgresql vacuum

2 respostas

  1. Best Answer

    1) Eu teria tentado agrupar seguido de análise. Minha única hesitação é que não tenho 100% de certeza do que aconteceu aqui. É possível que também tenha havido alguma corrupção de índice? Reindex pode ter ajudado? Dado que as entradas de estatísticas estavam erradas, é possível que algo estivesse corrompido em outro lugar em relação ao OID da relação?

    2) Não faço ideia. Eu nunca vi nada assim antes. Eu precisaria de muito mais informações de diagnóstico, mesmo para arriscar um palpite. Se acontecer novamente valeria a pena saber o tamanho físico da mesa, por exemplo.

    Editar: Lembrando que 8.4 ainda tinha max_fsm_pages, se isso fosse muito baixo entre os vácuos, isso poderia causar esse tipo de inchaço na tabela.

    Edit2: Vácuo cheio, no entanto, deveria ter sido capaz de lidar com o inchaço devido a max_fsm_pages, pelo menos na minha experiência, sugerindo novamente para mim que algo mais profundo estava errado.

    • 2

  2. Acho que finalmente encontrei uma resposta para 1) Qual teria sido o tratamento mais correto?

    Dica: Nenhuma das formas de VACUUM é totalmente satisfatória quando uma tabela contém um grande número de versões de linhas inativas como resultado de atualização massiva ou atividade de exclusão. Se você tiver tal tabela e precisar recuperar o excesso de espaço em disco que ela ocupa, a melhor maneira é usar CLUSTER ou uma das variantes de reescrita de tabela de ALTER TABLE. Esses comandos reescrevem uma nova cópia inteira da tabela e criam novos índices para ela. Assim como o VACUUM FULL, requerem travamento exclusivo. Observe que eles também usam temporariamente espaço extra em disco, pois as cópias antigas da tabela e índices não podem ser liberadas até que as novas sejam concluídas. No pior caso em que seu disco está quase cheio, VACUUM FULL pode ser a única alternativa viável. 1

    • 0

relate perguntas