Início / dba / Perguntas / 126826
Accepted
Michael Hooreman
Asked: 2016-01-21 23:52:50 +0800 CST

“usando estatísticas obsoletas em vez das atuais porque o coletor de estatísticas não está respondendo”

  • 772

Meus logs do postgresql 9.5 mostram a cada minuto a mensagem:

usando estatísticas desatualizadas em vez das atuais porque o coletor de estatísticas não está respondendo

Exceto um post sobre serverfault que não é útil e parece relacionado à configuração de bancos de dados em espera (que não é o meu caso), não encontro nada para resolver isso.

Qual é o significado disto? Como posso resolver isso?

Informações adicionais com base na resposta de Greda:

  • Eu tenho 4 CPUs e na rotina menos de 5% de 1 CPU é usado
  • Tenho 32Gb de RAM, e na rotina ~ 500Mb são usados
  • Isso não é uma VM
  • Isso executa o Ubuntu 14.04.3 LTS/Linux 3.13.0 SMB x86/64

Eu também tentei ajustar os parâmetros postgresql.conf da seguinte forma

  • buffer_compartilhado: 1024 MB
  • work_mem: 10 MB
  • Maintenance_work_mem: 1024 MB
  • Effective_cache_size: 4 GB

A mensagem de erro ainda está lá.

PS: Entendo perfeitamente que não é um erro grave, mas inunda meus logs e tenho medo de não ver mensagens importantes...

Algumas observações adicionais:

  • VACUUM FULL VERBOSE ANALYZEnão ajuda
  • Eu tenho um processo interminável conectado ao banco de dados. Quando está em execução, o VACUUM FULL VERBOSE ANALYZEparece bloqueado.

Esse processo sem fim pode ser a causa raiz do meu problema? Nesse caso, como preciso ter esse processo em execução, preciso ajustar algo no servidor?

Editar:

Eu tive um processo interminável conectado ao banco de dados. Eu tentei pará-lo, e isso não ajuda.

Meu arquivo postgresql.conf está disponível lá

postgresql postgresql-9.5

4 respostas

  1. Isso basicamente significa que sua máquina (virtual?) está muito lenta ou sobrecarregada, porque a tarefa em segundo plano do coletor de estatísticas está morrendo de fome. Ele está sendo executado com uma prioridade mais baixa por padrão, porque você não deseja que ele interrompa as operações normais do banco de dados (muito).

    Se você puder pagar, adicione mais algumas CPUs e certifique-se de ter bastante RAM.

    Tecnicamente, porém, este não é um erro grave - suas consultas serão executadas, mas podem estar usando planos de execução abaixo do ideal porque não viram uma atualização nas estatísticas da tabela por um tempo.

    Se desejar, você sempre pode forçar uma atualização de estatísticas para as tabelas alteradas com mais frequência executando as instruções ANALYZE ou VACUUM ANALYZE nelas.

    • 4

  2. Para aliviar temporariamente o problema até encontrar uma solução, você já tentou enviar um SIGHUP para o servidor quando isso ocorre?

    Eu tenho um problema semelhante em uma situação bastante diferente: o banco de dados é executado em um PC desktop com Windows junto com o Apache e o software proprietário de controle de máquina. Meu caso se encaixa na categoria "lento ou sobrecarregado". No entanto, vejo isso acontecendo mesmo à noite, enquanto a máquina está ociosa. Tenho monitorado muitos parâmetros do sistema com o PRTG para tentar encontrar um link com uma atividade específica, mas só consigo ver as consequências, não a causa.

    Não vejo isso como um aviso simples porque, uma vez iniciado, as consultas que normalmente levam 100 ms começarão a levar 10 segundos (mas ainda não afetarão outras consultas). Além disso, fica assim até que eu envie um SIGHUP (pg_ctl.exe reload ...), o que acho estranho, pois o processo deve ser retomado assim que não estiver mais faminto.

    PS, por favor, não me fale sobre a parte da área de trabalho do Windows: eu sei e ... circunstâncias.

    • 3
  3. Best Answer

    Desapareceu ao atualizar para 9.5.2.1 ( http://apt.postgresql.org/pub/repos/apt/ ), mas voltou após a reinicialização do servidor.

    Parece que foi devido ao reinício do serviço durante a instalação

    A solução é reiniciar o serviço.

    Pergunta encerrada

    • 2

  4. Isso aconteceu comigo quando desativei o IPv6 no servidor sem reiniciar o Postgres. Encontrei uma explicação detalhada aqui (procure por "O coletor de estatísticas" na página), mas resumindo:

    O PostgreSQL [...] irá percorrer todos os endereços retornados [para localhost], criar um soquete UDP e testá-lo até que tenha um soquete que funcione.

    Se o soquete selecionado for IPv6 e for desativado posteriormente, ele para de funcionar e você obtém essa mensagem nos logs.

    Você pode verificar a qual porta IP e UDP o serviço "postmaster" (ou "postgres") está vinculado

    netstat -n -u -p

    A saída é algo como isto:

    Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
udp        0      0 127.0.0.1:47780         127.0.0.1:47780         ESTABLISHED 2824/postmaster

    ou em outro host onde está vinculado ao IPv6 ("udp6"):

    # netstat -n -u -p
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
udp6       0      0 ::1:51761               ::1:51761               ESTABLISHED 1006/postgres

    Reiniciar o postgres conforme sugerido na resposta aceita realmente o corrige.

    • 1

relate perguntas