Boa tarde Angelo. Já pensou na possibilidade de executar um *clusterdb* para reorganizar os índices das tabelas mais utilizadas?
Isso pode ajudar na performance. Abraço! Thiago Bonfante. Em 4 de abril de 2011 11:57, Angelo -TI - LightComm <ang...@lightcomm.com.br > escreveu: > Reinaldo, boa tarde, > > Já migramos o servidor para uma máquina melhor, com o dobro de memória e já > acertamos algumas configurações do PostgreSQL para utilizar esta memória. > > Com isso o Banco de dados ganhou mais velocidade, mas acredito que um > Vacuum deixaria o servidor mais rápido (fiz isso em 10 tabelas e o acesso > aos dados delas melhorou muito). > > Obrigado pelas Respostas > > Qualquer dúvida, favor entrar em contato. > > Atenciosamente, > > Angelo M. Rodrigues > LightComm Tecnologia > Cml: (11) 3304-7717 > Celular: (11) 7821-8298 > Nextel: 54 * 13944 > www.lightcomm.com.br > ang...@lightcomm.com.br > > MSN: angelomrodrig...@hotmail.com > GTalk: angelomrodrig...@gmail.com > > Em 04/04/2011, às 11:46, Reinaldo de Carvalho escreveu: > > > 2011/4/4 Angelo -TI - LightComm <ang...@lightcomm.com.br>: > >> Meu cliente tem um banco de dados (PostgreSQL 8.0 c/ 200Gb de dados) que > está rodando há muito tempo e está tendo problemas de performance. > >> > >> O banco de dados dele é muito acessado e rodar um Vacuum Full no banco > inteiro não é possível, pois ao rodar ele acaba travando algumas tabelas que > são utilizadas constantemente. > >> > >> Fizemos uma cópia deste banco para uma outra máquina e rodamos um Vacuum > Full na tabela de Clientes e o mesmo demorou cerca de 8 horas para terminar. > >> > >> Será que se eu instalar e configurar o Auto Vacuum neste banco ele > conseguirá acertar este banco de dados, ou eu terei que rodar um vacuum full > neste banco antes de colocar para rodar o Auto Vacuum? > >> > >> O que vocês acham? > >> > > > > Por experiência, pode que apenas o Vaccuum não resolva. Pode ser o > > problema clássico de 'saturação do acesso a disco', que pode ser > > resolvido com: > > > > i) mais memória RAM, permitindo que o SO mantenha mais arquivos em > memória; > > ii) adquirindo hardware de maior capacidade de acesso a disco; > > iii) adicionando alguns nós para replicação, distribuindo as consultas > > entre estes; > > iv) revisando as consultas, alguns desenvolvedores* pensam que o > > hardware é ilimitado* ; > > > > > > * principalmente nessa época de EJB/JPA, que os desenvolvedores não > > imaginam quanto de dados estão sendo carregados para a o conteiner. > > > > -- > > Reinaldo de Carvalho > > http://korreio.sf.net > > http://python-cyrus.sf.net > > > > "While not fully understand a software, don't try to adapt this > > software to the way you work, but rather yourself to the way the > > software works" (myself) > > _______________________________________________ > > 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 >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
