Rodrigo,
aconteceu comigo e vai aqui minha experiência na solução do problema.
Cada vez que o VACUUM é interrompido sua base de dados fica com blocos
"sujos" (decorrentes da reorganização feita pelo VACUUM) e sempre maior.
A próxima execução do VACUUM será pior ainda se ele não executar até o fim.
Bom, para ajudar vale a pena alterar alguns itens de configuração do
servidor, do SGBD e de sua estrutura no sistema de arquivos.
Do servidor:
Você usa SATA, então pode ver se seu disco e controladora suporta alguma
otimização através do utilitário "hdparm".
Do SGBD:
a) Considere alterar os seguintes parâmetros no "postgresql.conf":
- maintenance_work_mem: de 10% até 20% da RAM livre. Por exemplo, se
tiver 1.5G livre (ou em cache), pode usar de 153M (10%) a 307M (20%).
no momento do VACUUM.
- max_fsm_relations: Maior número de tabelas e índices para os quais o
mapa de espaço livre é rastreado. Configure com o total de tabelas e
índices que tiver em TODAS as suas bases de dados, mais uma folga.
Por exemplo, se o total for 5000, use 10000 (dobro).
- max_fsm_pages: Maior número de páginas de disco para as quais o mapa
de espaço livre é rastreado. Configure com o total de páginas usadas
por tabelas e índices que tiver em TODAS as suas bases de dados, mais
uma folga. Por exemplo, se o total for 100000, use 200000 (dobro).
- checkpoint_segments: o default é 3, mas você pode aumentar para 32 ou 64,
sem problema, se tiver uns 2G livres em disco para armazenar os arquivos
do WAL. Vai minimizar a quantidade de reciclagem de logs de transação,
que geram muito I/O, que interfere bastante na performance durante um
VACUUM FULL.
- effective_cache_size: de 20% a 50% da RAM total. Por exemplo, para
seus 2G, use de 25% a 50%, dependendo do quanto deseja que o PostgreSQL
"entenda" que o Cache possa ser usado. Apesar de não ter relação direta
com o procedimento do VACUUM, pode ser interessante para o uso geral
de seu SGBD.
b) Considere usar o 'autovacuum' com uma configuração mais 'leve', com
VACUUM ANALYZE periódicos, de modo a tornar o processamento do VACUUM FULL
menos oneroso para o sistema.
c) Considere executar um REINDEX DATABASE para reconstruir os índices de
modo que seu tamanho diminua em disco e alivie um pouco o trabalho feito
pelo VACUUM. Lembre-se que após executar o REINDEX deve ser também executado
um ANALYZE. Faça isto se sua base sofrer muitas alterações de tuplas e não
deixe que se passe mais de uma semana sem executar.
d) Considere separar (em discos diferentes) o diretório de dados
($PGDATA/"base") do diretório do WAL ($PGDATA/pg_xlog). Isto diminui bastante
a concorrência na leitura/gravação dos arquivos do PostgreSQL.
e) O sistema de arquivos interfere muito na performance:
- Recomendo o XFS: é rápido, tem journal, baixo overhead de processamento
e mantém a performance na média, seja trabalhando com arquivos pequenos ou
arquivos grandes.
- ReiserFS 3.6 (não usar 4.x!!!) é muito rápido e tem journal, mas não é
indicado para arquivos muito grandes (leia-se arquivos das tabelas e índices
do banco), além de consumir muita CPU.
- EXT3 não deve ser usado pois é muito lento, apesar de usar journal.
- EXT2 é muito rápido, mas não usa journal e, por isto, não deve ser usado,
pois não te dará segurança segurança na recuperação após crashes.
A consulta abaixo pode te ajudar a encontrar os valores para "max_fsm_pages",
e "max_fsm_relations", mas deve ser executada em cada uma das bases de dados
na instância e antes dela, os dados da pg_class devem ser atualizados com um
ANALYZE.
-- INICIO SQL
ANALYZE;
SELECT COUNT(*) -- quantidade total de tabelas e índices
, SUM(relpages) -- quantidade total de páginas em disco
FROM pg_catalog.pg_class
WHERE relkind IN ('r','i') -- tabelas e índices
;
-- FIM SQL
Espero ter ajudado em alguma coisa.
Abraço.
http://funfou.blogspot.com/
Em Quinta 16 Agosto 2007 09:00, [EMAIL PROTECTED]
escreveu:
> Message: 6
> Date: Thu, 16 Aug 2007 08:15:55 -0300
> From: "Rodrigo Tazima" <[EMAIL PROTECTED]>
> Subject: [pgbr-geral] Travamento de Banco e Vacuum
> To: <pgbr-geral@listas.postgresql.org.br>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Olá Pessoal,
>
> Estou com uma dificuldade e venho compartilhar com o forum, qualquer
> dica/sugestao é bem vinda e agradeço a todos desde já.
>
> Hardware:
> . Servidor Dell PowerEdge SC440
> . Processador Pentium D 935 (2x2MB Cache, 3.2GHz 800MHz) FSB
> . 2GB Ram ECC
> . HD 160GB Sata2
>
> Software:
> . SO Suse 10.0
> . PostgreSQL 8.0.3
>
> Caso:
>
> O dump da base tem aproximadamente 2.6GB, algumas tabelas proximo de 3
> milhoes
> de registros. Aplicacao OLTP em 10 usuarios. Gerando aproximadamente 30 mil
> registros por dia. Tenho programado (via cron + shell) o vacuumdb (FULL)
> todos os dias as 23:45. O que
> ocorre é que há dias que parece que o banco "trava" rodando o vacuum.
> Amanhece e
> vejo os processos e o vacuum ainda esta rodando e o banco nao responde, da
> impressão que o banco trava ou pelo menos nao responde, se tento conectar
> fica parado esperando, nao da erro de conexao e nem timeout. Nao consigo
> dar shutdown no banco e nem dar kill nos processos do postmaster, a unica
> forma é reiniciando todo o servidor. Parece que ocorre um lock (ou
> deadlock) interno, o banco fica idle e nao responde.
>
> Os parametros do postgresql.conf que estou utilizando fora do default que
> estou utilizando sao:
>
> shared_buffers = 65536
> work_mem = 8192
> maintenance_work_mem = 16384
>
> fsync = false
>
> redirect_stderr = true
> client_min_messages = log
> log_destination = 'stderr'
> log_directory = 'pg_log'
> log_min_messages = log
> log_min_error_statement = info
> log_connections = true
> log_disconnections = true
> log_duration = true
> log_line_prefix = '<%t %u %r>'
>
> stats_start_collector = true
> stats_row_level = true
>
> Alguem passou por alguma situação semelhante? Procurei pela internet este
> caso, porem sem sucesso.
>
> Obrigado...
>
> Abraço a todos...
>
> Rodrigo
>
> -------------- Próxima Parte ----------
> Um anexo em HTML foi limpo...
> URL:
> http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20070816/8
>7a0d0b2/attachment-0001.htm
--
/*
Guilherme Augusto da Rocha Silva
Administração de Dados / Bancos de Dados
Gerência de Tecnologia da Informação
SIM Instituto de Gestão Fiscal
*/
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
