Demasiada E / S gerada pelo processo coletor de estatísticas do postgres

Estou usando o XenServer com várias máquinas virtuais com bancos de dados locais do postgres. Mesmo quando todos os aplicativos não são utilizados e os bancos de dados estão ociosos, cada vm causa tráfego constante na rede de armazenamento, o que prejudica o desempenho do dispositivo de armazenamento iscsi.

Após a execução iotop, observei que o processo do coletor de estatísticas do postgres está gravando constantemente no disco a uma taxa de cerca de 2 MByte / s.

Desativei a coleta de estatísticas editando /etc/postgresql/8.4/main/postgresql.conf:

#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------

# - Query/Index Statistics Collector -

track_activities = off
track_counts = off
...

conforme sugerido em http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htm .

Isso eliminou a gravação contínua, mas existem desvantagens em desativar o rastreamento de estatísticas?

Ou devo colocar o diretório pg_stat_tmp em um ramdisk para evitar o tráfego de disco / rede?

O sistema é um Debian 6.0.7 (squeeze) atualizado com o postgres 8.4 e cerca de 20 bancos de dados com cerca de 50 tabelas; o tamanho total do arquivo de despejo é inferior a 100 MByte.

Como a atualização do PostgreSQL não é uma opção, tentei colocar o diretório pg_stat_tmp em um sistema de arquivos tmpfs, o que proporcionou uma melhoria significativa no desempenho. Agora, estou executando isso em algumas dezenas de sistemas por alguns meses, sem nenhum inconveniente perceptível.

Para fazer isso, basta montar pg_stat_tmp com tmpfs no seu arquivo / etc / fstab:

# <file system> <mount point>                                <type>  <options>  <dump>  <pass>
tmpfs           /var/lib/postgresql/8.4/main/pg_stat_tmp     tmpfs   defaults,noatime,mode=1777,uid=postgres,gid=postgres,nosuid,nodev 0 0

Atualize o PostgreSQL. No mínimo absoluto, verifique se você está na versão 8.4 mais recente; se isso não for resolvido e for prático, você provavelmente deve atualizar para a 9.2. Pelo menos alguns problemas em torno do coletor de estatísticas foram abordados desde a 8.4 e chegarão ao fim da vida útil em cerca de um ano . Você pode encontrar mais informações pesquisando nos arquivos da lista de discussão pgsql-general .

Você não deve ter muitos problemas atualização 8,4-9,2, embora, como de costume, você deve ler a seção de atualização das notas de lançamento para cada inbetween 0,0 versão (9.0, 9.1 e 9.2). Preste especial atenção a standard_conforming_stringse bytea_output.

Mesmo problema aqui. Eu também desabilitei track_*e assim por diante.

O efeito colateral autovacuumé o uso desses dados coletados para iniciar.

Então, eu tenho o cuidado de agendar todas as noites a vacuumdb.

Outra solução é definir um valor autovacuum_naptimemais alto para ter o sistema em repouso.