Vinicius, O Guilherme foi bem mais preciso sobre as considerações sobre tunning. Sugiro avaliar os criterios dele.
A ideia é o uso de uma analyze, para que a escolha de indices seja a mais adequada, de acordo com critérios gerenciados pelo BD. Observe que ele põe a ressalva de nao passar de 1 semana sem processamento de estatísticas de pesquisa. Guilherme, Como disse, estou retomando. Gostrei de sua abordagem, bem completa ! Vou tomar por base em meus estudos :) Sds, Marco Antonio Vinicius wrote: > O problema q se eu nao rodar o vacuum full diariamente, chega um ponto q > minha base fica mto lenta para pesquisas, e fica juntanto mto lixo no banco, > e por fim nao consigo executar mais o vacuum full e tenho q fazer um backup > e restore da base. > > Como eu disse rodo 2x por dia vacuum not full com analyze. > Sobre discos eu tenho 4 discos SCSI 15k controladora U320,,, com 2 raid's 1. > dai divido estas duas tabelas e indices d maior tamanho,, entao no 1o. raid > deixo a tabela de 25milhoes e seus indices, e no 2o. raid a tabela de > 30milhoes d registros e seus indices,, o restante das tabelas q sao bem > menores ficam todas no raid 1. > > > > ----- Original Message ----- > From: "Marco A P D´Andrade" <[EMAIL PROTECTED]> > To: "Comunidade PostgreSQL Brasileira" <[email protected]> > Sent: Thursday, August 16, 2007 5:50 PM > Subject: Re: [pgbr-geral] Travamento de Banco e Vacuum > > > 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" >> <[email protected]> >> 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 >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> 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 [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
