> > > 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.
Por isso coloquei: "pensar/*analisar*". E concordo com sua afirmação, eu deveria ter explecitado isso, mas colocar um pgpool pode até piorar o cenário. > 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 > E o melhor, ele te dá gráficos que podem ser mostrados pra usuários comuns, ajudando na comparação do antes e depois. > > 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. Na verdade acho que a "recomendação" seria analisar a fundo a arquitetura do sistema para decidir a melhor estratégia. Como ele disse que usava um ERP, eu assumi (agora aqho que erroneamente) que as operações de leitura seriam feitas em dados mais recentes, exemplo: vendas mais recentes. Logo, se os dados são recentes, poderiam (deveriam?) estar em cache. Claro que se a aplicação, como em DWs e OLAPs, recupera e processa muitos dados, não dá pra colocar tudo em cache mesmo. Como o ambiente dele *parece* ser meio heterogêneo, o ideal seria tentar encontrar um balanço do work_mem e shared_buffers (e relacionados). Não lembro se alguém citou, mas recomendo uma lida em [1]. No mais, use o sar (veja que isso já foi dito várias vezes) + kSar para analisar a situação atual e *começar *a investigar a causa da lentidão. [1] http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server Atenciosamente, -- Matheus de Oliveira
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
