>
> 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).

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

Responder a