> 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).
Colocar mais coisas num ambiente sem identificar a real causa de problemas não é a melhor estratégia. > 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. Realmente, o kSar é uma mão na roda. Uso sempre e sem moderação. > 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). Cuidado aí! A recomendação é justamente ao contrário: bancos de dados onde se privilegiam a leitura (DWs, OLAPs e afins) deveriam usar *menos* memória no cache (dentro de shared_buffers) e um pouco mais em work_mem para privilegiar ordenações e agregações. Não existe mágica: banco de dados e discos rápidos são os melhores amigos. []s Flavio Henrique A. Gurgel Consultor e Instrutor 4Linux Tel: +55-11-2125-4747 www.4linux.com.br _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
