Olá, Em 19 de março de 2010 10:08, Pablo Sánchez <[email protected]> escreveu:
> Caros, > > Estamos com um pequeno, mas não muito grande, problema. Estamos > realizando a apresentação do sistema que desenvolvemos rodando em um > notebook. O problema é que ao pendurar 40 usuários simultâneos > acontecem algumas coisas meio estranbólicas. O sistema utiliza muitas > construções hierárquicas, ou seja, ele tem muitas estruturas em árvore > (eu pessoalmente acho que o gargalo começa aí, mas o outro analista > que está há 2 anos no projeto acha que não - só que vendo o código que > existe, aff maria, tem nem por onde começar a desfazer o macarrão > desorientado a objetos que foi criado antes de eu entrar nesse > projeto!). > > Para praticamente tudo, ele inicia transações, inclusive para > consultas. Nisso, já tem um dos vários gargalos que temos que desfazer > (comecei por aí), afinal de contas, para consultas, transações são > indiferentes, não precisa dar um rollback nunca, então, é meio que > inútil fazer isso. > > Se você se referindo a consultas do tipo SELECT realmente não existe a mínima necessidade abrir uma transação (BEGIN) e terminá-la com um COMMIT. > Outra coisa que estamos fazendo, só para as apresentações (afinal de > contas, o note onde está rodando o sistema não é nenhum servidor, né?) > é desativar o fsync. > Em produção não aconselho a trabalhar o com o fsync desabilitado. Agora um lembrete: Não esqueça de deixar ON este parâmetro em produção. > > Já andei vendo várias outras otimizações possíveis no postgres, que é > quem está realmente morrendo, mas não resolveu-se 100% ainda. Porque > eu afirmo que é o PG, e não o Apache? Simples, porque as mensagens de > erro são "Desculpe, excedido o limite de conexões simultâneas" - > colocamos para 80, e ainda assim.... E outra mensagem drástica foi > "Postgres está desligando". Não eram essas as exatas palavras, eram as > mensagens do PG mesmo, repassadas ao PHP e então enviadas aos > navegadores. Terrível! > Aqui faço algumas ressalvas. Como você pode ter certeza de que é o Apache e não o PG. Eu não afirmaria sem antes analisar tudo que está envolvido para achar o problema. Já tive vários problemas de performance, em um deles o load do servidor PostgreSQL estava sempre alto e do aplicação baixo e a aplicação sempre travava. Depois de várias analises descobriu-se que o problema era o memory_limit do PHP. Nesta questão eu sou bem cuidadoso e gosto sempre de me certificar do problema para ai sim buscar as devidas soluções. Qual ao erro de limite de conexões, assim é claro que o número de conexões excedeu o limite. Agora uma pergunta. Como estão sendo feitas estas conexões? Pelo que percebo elas não estão sendo fechadas, e sempre novas conexões são abertas e as conexões já utilizadas ficam abertas. Você já pensou em usar algum pool de conexões? > > Já verifiquei uma coisa no código: é aberta apenas uma conexão por > requisição, ou seja, se temos 40 máquinas conectadas, 80 conexões > simultâneas permitidas, a princípio isso não deveria ser o problema. > > Alguém tem alguma outra dica de otimização do PostgreSQL? > Quais parâmetros do PG você já configurou? Qual versão do PG você está utilizando? Já deu uma olhada no pgtune [1]? [1] http://pgfoundry.org/projects/pgtune/ > Outra, e mais importante: precisamos de uma ferramenta de > monitoramento do PostgreSQL, uma decente, preferencialmente gratuita, > ou pelo menos shareware para 30 dias. Alguém tem uma boa dica de > ferramenta? > O sistema roda sobre qual plataforma? Windows ou Linux? No Linux você tem várias ferramentas de diagnóstico. De uma olhada no sar (ferramente bem genérica), iostat (monitora I/O) e vmstat (monitoramento de SWAP). Para análise de consultas sugirou o PgFouine [2]. [2] http://pgfouine.projects.postgresql.org/ Acho que um caminho está dado, além disso tem muitas outras coisas. > > -- > ================================= > Pablo Santiago Sánchez > [email protected] > (61) 9975-0883 > http://www.sansis.com.br > "Quidquid latine dictum sit, altum viditur" > ================================= > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > []s -- JotaComm http://jotacomm.wordpress.com
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
