Verônica, Questão de manutenção em paralelo dessa tabela VACUUM e REINDEX está ok ?
Uma questão importante a ser considerada também se essa tabela esteja em uma tablespace para um local específico pois aí envolve também a questão dos I/O de discos. Outra questão importante é a quantidade de registros e também se obteve uma carga enorme sobre essa tabela que está com a situação crítica. Uma prática que não é muito utilizada até pela disponibilidade do banco de dados, e a recriação do database, já resolvi problemas de performance com PostgreSQL recriando a base de dados. Dependendo da sua visão quanto ao questionamento acima, repense na questão do modelo de dados, veja esses conceitos de particionamento, confesso que nunca utilizei na prática com PostgreSQL, mas realizei alguns testes e realmente dá um resultado positivo. Dependendo do volume de dados as vezes nos obriga a ter que fazermos algo no modelo mesmo. exemplo simples de particionamento: http://keniamilene.wordpress.com/2008/05/26/particionamento-de-tabelas-no-postgresql/ Espero contribuir dessa forma, pois sem olhar para o cenário/ambiente fica difícil apenas pelos parâmetros da configuração. Att Rodrigo Em 23 de março de 2012 16:31, veronica almeida < veronika.alessan...@gmail.com> escreveu: > Oi, Flavio! > > Alterei as configurações de shared_buffers para 10GB, e como o work_mem > está baixo, alterei o effective_cache_size para 15GB, alterei também o > checkpoints_segments para 74 com essa alteração o uso de memória diminuiu, > mas o tempo de execução das consultas continua alto. De maneira geral todas > as consultas estão mais lentas, mas a principal tabela com problema é a > apresentada abaixo: > > Log Postgres/Programa PHP no servidor: > ip=127.0.0.1LOG: duration: 16.224 ms statement: SELECT > round(min(temperatura)) as min, round(max(temperatura)) as max FROM > temperatura where > previsao_idPrevisao=get_processamento_previsao('2012-03-25',1,1) and > cidade_idCidade = '2019'; > > Execução da mesma consulta, usando o PgAdmin: > -- Executing query: > SELECT round(min(temperatura)) as min, round(max(temperatura)) as max FROM > temperatura where > previsao_idPrevisao=get_processamento_previsao('2012-03-25',1,1) and > cidade_idCidade = '2019'; > Total query runtime: 1227 ms. > 1 row retrieved. > > Explain analyze: > "Aggregate (cost=87.07..87.08 rows=1 width=8) (actual time=0.029..0.029 > rows=1 loops=1)" > " -> Index Scan using temperatura_new_pkey1 on temperatura > (cost=0.00..86.94 rows=24 width=8) (actual time=0.013..0.022 rows=24 > loops=1)" > " Index Cond: ((previsao_idprevisao = 313391) AND (cidade_idcidade > = 2019))" > "Total runtime: 0.052 ms" > > Obrigada pela ajuda!! (-: > > >> Message: 2 >> Date: Fri, 23 Mar 2012 13:37:13 -0300 >> From: Flavio Henrique Araque Gurgel <fha...@gmail.com> >> Subject: Re: [pgbr-geral] Lentidão >> To: Comunidade PostgreSQL Brasileira >> <pgbr-geral@listas.postgresql.org.br> >> Message-ID: >> <CAGHTAePU4H-OKmyqT34PgE_FqKEkow8Jn=OoLb5= >> dr6qr3l...@mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Olá Veronica, tente manter o assunto nas suas respostas pra não gerar >> threads paralelas e manter a lista organizada. >> Mais respostas abaixo: >> >> > O uso de swap é muito baixo. >> > >> > O uso de memória realmente é alto, porém mesmo usando comando para >> liberar a >> > memória, eliminação de processos e restart no servidor, o tempo de >> execução >> > das consultas permanece muito alto. >> > >> > Você consegue me indicar se estes números estão ruins? >> > >> > >> checkpoints_timed;checkpoints_req;buffers_checkpoin;buffers_clean;maxwritten_clean;buffers_backend;buffers_alloc >> > 779;129;8689880;166544;1464;6552081;30762514 >> >> Parece que você pode aumentar um pouco checkpoint_segments, tem muitos >> checkpoints começando por falta de segmentos (~20%). Mas isso só vai >> afetar escrita (INSERT, UPDATE, DELETE), não leitura.(SELECT). >> Aumentar um pouco shared_buffers também parece uma boa idéia, pois >> parece que há muita escrita direta pelos backends, fora dos >> checkpoints (buffers_backend). >> >> Cuidado pra não estourar a RAM do servidor aumentando shared_buffers. >> Na dúvida, aumente shared_buffers diminuindo work_mem um pouco. >> >> Mas pra otimizar mesmo, que tipo de consulta está lenta? >> Tem como passar o plano de execução (EXPLAIN ANALYZE) dela? >> >> []s >> Flavio Gurgel >> >> >> ------------------------------ >> >> Message: 3 >> Date: Fri, 23 Mar 2012 13:49:43 -0300 >> From: "Erison Gmail" <nos...@gmail.com> >> Subject: [pgbr-geral] RES: Tunning Postgresql >> To: <pgbr-geral@listas.postgresql.org.br> >> Message-ID: >> >> >> <!&!AAAAAAAAAAAYAAAAAAAAAOQEzae9YblAjdlmmQwfYVvCgAAAEAAAAAUKsc47SBBOgsgTYQiw0fcBAAAAAA==@ >> gmail.com> >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Boa tarde >> >> Estou sendo vago, mas não sei como questionar, o que queria era utilizar >> melhor o hardware que tenho, para poder diminuir o tempo de >> execução,diminuir tempo de resposta, o que me refiro, salvo engano, que ao >> melhorar o hardware o sgbd teria(hipoteticamente) que ser otimizado para >> melhor usar o hardware disponível!!! >> >> Desculpem minha ignorância. >> >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 23 Mar 2012 13:53:05 -0300 >> From: Flavio Henrique Araque Gurgel <fha...@gmail.com> >> Subject: Re: [pgbr-geral] RES: Tunning Postgresql >> To: Comunidade PostgreSQL Brasileira >> <pgbr-geral@listas.postgresql.org.br> >> Message-ID: >> < >> caghtaepclryctx+cv98mgqevt6b0jscyigoalx37z214lem...@mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> > Estou sendo vago, mas não sei como questionar, o que queria era utilizar >> > melhor o hardware que tenho, para poder diminuir o tempo de >> > execução,diminuir tempo de resposta, o que me refiro, salvo engano, que >> ao >> > melhorar o hardware o sgbd teria(hipoteticamente) que ser otimizado para >> > melhor usar o hardware disponível!!! >> >> Sim. >> E o SGBD tem que ser também ajustado às necessidades de sua aplicação. >> É um conjunto: dependendo do que sua aplicação precisa, direcionam-se >> mais recursos do hardware para isso. >> Não é o SGBD que aproveita o hardware, é a aplicação que, através do >> SGBD, aproveita o hardware. >> Por isso te perguntamos: o que é sua aplicação, o que ela faz, que >> tipo de consultas, etc... >> >> []s >> Flavio Gurgel >> >> >> ------------------------------ >> >> Message: 5 >> Date: Fri, 23 Mar 2012 14:02:44 -0300 >> From: Leandro Guimarães Faria Corce DUTRA <l...@dutras.org> >> Subject: Re: [pgbr-geral] RES: Tunning Postgresql >> To: Comunidade PostgreSQL Brasileira >> <pgbr-geral@listas.postgresql.org.br> >> Cc: Erison Gmail <nos...@gmail.com> >> Message-ID: <4f6cacb4.5020...@dutras.org> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Le 2012-M-23 13h49, Erison Gmail a écrit : >> > >> > Estou sendo vago, mas não sei como questionar >> >> A questão não é como questionar: é que não temos as informações mínimas >> para poder te ajudar. >> >> >> > o que queria era utilizar >> > melhor o hardware que tenho, para poder diminuir o tempo de >> > execução,diminuir tempo de resposta >> >> Então tens de nos dar configurações, comandos, estruturas, estatísticas >> e planos de execução que queres melhorar. >> >> >> >> -- >> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra >> +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org >> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 >> BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm >> >> >> ------------------------------ >> >> Message: 6 >> Date: Fri, 23 Mar 2012 14:04:22 -0300 >> From: Carlos Henrique Botelho <carloshenrique.c...@gmail.com> >> Subject: Re: [pgbr-geral] Não consigo conectar o PgAdmin III >> To: Comunidade PostgreSQL Brasileira >> <pgbr-geral@listas.postgresql.org.br> >> Message-ID: >> <CAN8AuBMk9Lb1TAg20-ux9JNP=QBWiOxWu16bcnkN= >> vhremx...@mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> (KSTROS) - Jayron Alberth Costa Castro >> negativo... fiz o que você pediu e segui o tutorial.... nem chega na parte >> do initdb.... ele não aparece as linha de comando... diz que não é um >> comando interno. >> Inclui via prompt e tbm pelas variaveis de ambiente... sem retorno! >> >> Em 23 de março de 2012 13:24, Carlos Henrique Botelho < >> carloshenrique.c...@gmail.com> escreveu: >> >> > Dá uma olhada na imagem abaixo >> > http://imageshack.us/photo/my-images/718/postgresql.png/ >> > >> > Em 23 de março de 2012 13:16, Carlos Henrique Botelho < >> > carloshenrique.c...@gmail.com> escreveu: >> > >> > Juliano dá uma olhada na imagem por favor >> >> >> >> Em 23 de março de 2012 11:31, Juliano Benvenuto Piovezan < >> >> juli...@sinersoft.com.br> escreveu: >> >> >> >> 2012/3/23 Carlos Henrique Botelho <carloshenrique.c...@gmail.com> >> >>> > >> >>> > Juliano Benvenuto Piovezan juli...@sinersoft.com.br por >> >>> listas.postgresql.org.br >> >>> > >> >>> > C:\Program Files\PostgreSQL\9.1\bin> pg_ctl -D c:\Program >> >>> Files\PostgreSQL\9.1\data start >> >>> > pg_ctl: mode de operação "Files\PostgreSQL\9.1\data" é desconhecido >> >>> > Tente "pg_ctl --help" para obter informações adicionais >> >>> > >> >>> >> >>> Coloque o caminho do diretório entre aspas duplas: >> >>> >> >>> pg_ctl -D "c:\Program Files\PostgreSQL\9.1\data" start >> >>> >> >>> Ou mesmo, pode utilizar o caminho relativo, já que você está no bin: >> >>> >> >>> pg_ctl -D ..\data start >> >>> _______________________________________________ >> >>> pgbr-geral mailing list >> >>> pgbr-geral@listas.postgresql.org.br >> >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >>> >> >> >> >> >> >> >> >> -- >> >> Att >> >> >> >> Carlos Henrique Botelho >> >> Cel.: (17) 9148-9033 >> >> twitter: @contabil_carlos >> >> >> >> >> > >> > >> > -- >> > Att >> > >> > Carlos Henrique Botelho >> > Cel.: (17) 9148-9033 >> > twitter: @contabil_carlos >> > >> > >> >> >> -- >> Att >> >> Carlos Henrique Botelho >> Cel.: (17) 9148-9033 >> twitter: @contabil_carlos >> -------------- Próxima Parte ---------- >> Um anexo em HTML foi limpo... >> URL: >> http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20120323/040ce17a/attachment.htm >> >> ------------------------------ >> >> _______________________________________________ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >> Fim da Digest pgbr-geral, volume 39, assunto 80 >> *********************************************** >> > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- *Atenciosamente* * * *Rodrigo Della Justina* *rodrigodellajust...@gmail.com* *rodrigodellajust...@ciss.com.br* Telp: 55-46-8801-6165 *IBM DB2 Certified Database Academic* * *
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
