Em 9 de maio de 2012 08:51, Matheus de Oliveira <[email protected]>escreveu:
> Nessa troca estou melhorando servidor e memoria (vai ficar 2X melhor a >> nivel de hardware). >> > > Cuidado, nem sempre melhorar o hardware resolve o problema, é melhor > encontrar e "se" for hardware invista especificamente no que resolverá o > problema (se chefia paga por hardware e não vê benefícios, cabeças rolam, > se não pagam nada e aparece o benefício, os cabeças são promovidos...=P). E > lembre-se que "pode" nem ser o servidor do banco o problema, veja se não é > um web-server, rede, etc. > > >> A questao de quantidades de conexao faz sentido e ja foi identificada uma >> melhoria. >> > > Uma dicca: como há várias aplicações conectando, você pode pensar/analisar > a possibilidade de utilizar o pgpool-II [1] tanto para pool de conexões, > quanto para load balance, se aplicável (veja que a melhoria aqui pode não > ser tão grande, precisaria de uma análise melhor das aplicações). > > > Resumindo, ja verifiquei essas outras variaveis, só estou com problemas em >> como medir/analisar a parte de Redes. Tipo, quais os detalhes que um DBA >> deveria analisar na rede, quais os valores aceitaveis e nao aceitaveis em >> relacao ao banco de dados. >> (Preciso medir isso antes da troca de maquina/versao pra nao ficar com um >> problema camuflado) >> > > O que já foi dito, mas acho que com pouca ênfase, é o uso do sar, na > verdade o uso do pacote sysstat. Recomendo também usar o kSar [2], > facilita, *e muito*, a análise dos resultados do sar, com isso você vai > ter como analisar: rede, disco (que "pode" ser o seu problema, e não rede), > cpu, memória, etc. > > Outra coisa, use a contrib pg_buffercache [3] pra analisar o quanto o > PostgreSQL está usando de dados em cache (como você tem bastante memória, > espera-se menos acesso à disco, claro que depende do tipo de aplicação, > e.g., aplicações que fazem muita leitura "deveriam" ler a maioria dos dados > da memória). > > Outras análises que devem ser feitas: uso do vaccuum, locks, I/O wait, > load avg, etc. Pra análisar o disco (independente do banco), recomendo o > Bonnie++[4]. > > Por fim, parece que você tem vários bancos, considere, se possível, > colocar "arquivos" mais acessados em discos mais potentes (usando > tablespaces ou links simbólicos). Em muitos casos, coloca-se o pg_xlog em > outra partição (é só montar a partição e fazer um link simbólico). > Acho até que o pg_xlog pode ficar em outro disco, claro que sempre depende da análise da situação. > > Bom, acho que é só o que eu posso dizer com as informações que você > passou, o primeiro passo acho que seria mesmo fazer análises com sysstat + > kSar. > > [1] http://www.pgpool.net/ > [2] http://sourceforge.net/projects/ksar/ > [3] http://www.postgresql.org/docs/9.1/static/pgbuffercache.html > [4] http://www.coker.com.au/bonnie++/ > > Atenciosamente, > -- > Matheus de Oliveira > > > _______________________________________________ > 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
