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