Em 20 de março de 2010 12:27, Pablo Sánchez <[email protected]> escreveu:
> 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... > Estranho o pgtune ter esculhambado o postgresql.conf, pois ele não altera o conf, ele apenas faz sugestões dos parâmetros, tanto é que você pode testar pelo tipo de aplicação, número de conexões por exemplo. > > > > >> > >> 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 > []s -- JotaComm http://jotacomm.wordpress.com
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
