Senhores,
Algo que me chamou a atenção, na questão do Rodrigo é a configuração de
maintenance_work_mem [1].
Considerando-se 2G de memoria, aumentar isto me parece uma boa opção !
Sobre tunning de memoria:
Quando ao shared_buffers, lembro que existem algums valores "magicos"
que devidamente ajustados fazem o banco melhorar muito de performance, e
claro, devem ser ajustados no SO antes, alguem recorda se esta é uma das
variaveis ?
Sobre AUTOVACUUM:
Por outro lado, se não me falha a memoria, se vc habilita o autovacuum,
vc não precisa e não deve, rodar o vacuum manualmente, pois vale a
ressalva de que um vacuum sem analyze não me pareceu ter o melhor resultado.
Sobre vacuum frequente:
Vinicios,
Vale a ressalva de que o vacuum tem por objetivo recuperar areas de
banco liberadas, não traz beneficio para inserções !
Talvez o que vc queira é um analyze, para melhorar estatísticas de
índice...
Estou retornando às origens, e à administração de banco de dados, e
terei logo de cara uma plataforma no nivel que vc tem... (volume e
hardware)... minha primeira preocupação é distribuição de tabelas em
discos distintos, quando possível (vc citou "discoS" scsi). Outro ponto
a trabalhar, antes de vacuum ou analyze são indices...
[1] http://www.postgresql.org/docs/8.0/static/runtime-config.html
Espero ter contribuido, pois estou "retornando" ;)
Sds,
Marco Antonio
Vinicius wrote:
> Aproveitando o assunto tenho o mesmo problema,, mas depois d algumas horas o
> vacuum full termina, tem dias q demora 40min. outros 4hrs, passo um vacuum
> nao full 2x ao dia e um vacuum full as 3hrs da madrugada.
> Pergunta:
> Se eu ligar o auto vacuum eu nao preciso mais passar o vacuum full ?
>
> Vou passar os dados do meu server e base
>
> Servidor com 2 cpus Xeon 3.0 / 16gb Ram / HD's SCSI
> Base com 70GB
> 2 Tabelas sao bem críticas uma tem 30milhoes d registros outra 25milhoes
> Essas duas tabelas recebem 1500 inserts por minuto, fora pesquisas q sao
> mtas.
>
> Se alguem puder me passar alguma dica para q nao seja necessario passar o
> vacuum full, pois o banco fica travado durante a madrugada praticamente e
> isso nao eh o ideal pois nosso sistema roda 24hrs.
>
>
> ----- Original Message -----
> From: "Osvaldo Rosario Kussama" <[EMAIL PROTECTED]>
> To: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br>
> Sent: Thursday, August 16, 2007 2:35 PM
> Subject: Re: [pgbr-geral] Travamento de Banco e Vacuum
>
>
> Rodrigo Tazima escreveu:
>
>> 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.
>>
>>
>
>
> Utilize a opção --verbose (ou -v) do vacuumdb para obter mais informações.
> Dê um ps auxww e verifique o status do vaccuum. Se estiver waiting então
> está agurdando a liberação de algum lock.
> Verifique se existe algo na view pg_locks que esteja bloqueando o
> vacuum, provavelmente nas tabelas do sistema.
> Verifique também, caso utilize, se existem prepared statements não
> comitados (pg_prepared_xacts).
>
> Osvaldo
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
--
Marco Antonio P D'Andrade
Gerência Técnica de Segurança de Suporte Servidores IP - ELN120024
Embratel - Rio de Janeiro - RIT 521-4898
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
