Em 19 de março de 2010 10:32, JotaComm <[email protected]> escreveu: > Olá, > > Em 19 de março de 2010 10:08, Pablo Sánchez <[email protected]> escreveu: >> 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.
Por isso escrevi "só para as apresentações". >> >> 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. Ok, vamos dar uma olhada no memory_limit, embora ele esteja alto já (128M - o padrão, para dizer a verdade). > 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? Deixamos a cargo do próprio PHP encerrar as conexões, nunca tivemos problemas nesse ponto antes, mas como o rapaz aqui está usando Ubuntu, e eu não confio nessa porcaria (no meu note, FreeBSD com a mesma carga de usuários e nenhuma otimização adicional foi necessária), vai ver que o PHP dele anda naquelas versões velhas com a desculpa esfarrada de pacote "safe". :-/ >> 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/ Sim, o pgtune esculhambou com o postgresql.conf de tal maneira que o postgres nem subia mais. :-D Fizemos na mão alterações em conexões, shared buffers e o tradicional quando se fala em otimização. Já deu uma melhorada, mas vou ver o memory_limit do PHP também... > >> >> 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? Cara, como te disse, está apenas no notebook do rapaz em um Linux, dando problemas, no meu note, FreeBSD vai sem problemas e a versão em produção está em Windows, e também sem problemas. Acho que vou converter o rapaz aqui para FreeBSD. :-D > 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. Valeu, vamos dar uma olhada. -- ================================= 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
