Em 27 de fevereiro de 2013 15:19, Renato Sousa <renso...@gmail.com>escreveu:
> > > Em 27 de fevereiro de 2013 14:35, Juliano Atanazio <juliano.l...@gmail.com > > escreveu: > > >> >> Em 27 de fevereiro de 2013 14:23, Renato Sousa <renso...@gmail.com>escreveu: >> >> >>> >>> Em 27 de fevereiro de 2013 12:17, Juliano Atanazio < >>> juliano.l...@gmail.com> escreveu: >>> >>> Em 27 de fevereiro de 2013 12:06, Renato Sousa <renso...@gmail.com>escreveu: >>>> >>>> >>>>> >>>>> Em 27 de fevereiro de 2013 11:30, Juliano Atanazio < >>>>> juliano.l...@gmail.com> escreveu: >>>>> >>>>> >>>>>> >>>>>> Em 27 de fevereiro de 2013 11:22, Renato Sousa >>>>>> <renso...@gmail.com>escreveu: >>>>>> >>>>>> >>>>>>> >>>>>>> Em 27 de fevereiro de 2013 10:35, Fábio Telles Rodriguez < >>>>>>> fabio.tel...@gmail.com> escreveu: >>>>>>> >>>>>>> Em 27 de fevereiro de 2013 10:21, Renato Sousa >>>>>>> <renso...@gmail.com>escreveu: >>>>>>>> >>>>>>>>> Bom dia amigos da lista, >>>>>>>>> >>>>>>>>> >>>>>>>>> Tenho um problema de performance em servidor que possui DB >>>>>>>>> postgres. Não sei ainda se o problema é ou não com o postgres, mas >>>>>>>>> gostaria de ajuda do pessoal da lista para descobrir isso. >>>>>>>>> O servidor faz a autenticação com wireless freeradius. Desconfio >>>>>>>>> que seja ele pois nos momentos de lentidão vejo o freeradius no topo >>>>>>>>> do >>>>>>>>> iotop. >>>>>>>>> >>>>>>>> >>>>>>>> Olhando o TOP normal, como fica a coluna "WA", ou wasted. Esta >>>>>>>> coluna indica espera de I/O. Isso junto com a sua observação do iotop >>>>>>>> pode >>>>>>>> matar a charada. Valores de 2, 3, 4 são normais. Se passar disso >>>>>>>> começa a >>>>>>>> complicar. Com mais de 10, você tem perda bem perceptível de >>>>>>>> performance >>>>>>>> para todo mundo. >>>>>>>> >>>>>>>> Outras coisas para olhar: >>>>>>>> 1) Consegue simular a mesma carga sem o radius? Eu já fiz testes >>>>>>>> com o pgbench[1] para isso. Simulei as conexões com e e sem o SSL e vi >>>>>>>> que >>>>>>>> numa situação onde muitas conexões abrem e fecham suas conexões (opção >>>>>>>> -C), >>>>>>>> o overhead é bem alto. >>>>>>>> 2) Use o pg_stat_statments para avaliar se algum SQL específico >>>>>>>> está demorando demais. >>>>>>>> 3) Configure corretamente os seus logs e verifique a sua saída. >>>>>>>> Muitas vezes a resposta está lá. >>>>>>>> 4) Atualize para o PostgreSQL 9.2. A diferença de performance é >>>>>>>> notável. >>>>>>>> >>>>>>>> [1] http://www.postgresql.org/docs/current/static/pgbench.html >>>>>>>> >>>>>>>> >>>>>>>> []s >>>>>>>> -- >>>>>>>> Atenciosamente, >>>>>>>> Fábio Telles Rodriguez >>>>>>>> blog: http:// >>>>>>>> <http://www.midstorm.org/%7Etelles/>s<http://tellesr.wordpress.com/> >>>>>>>> avepoint.blog.br >>>>>>>> e-mail / gtalk / MSN: fabio.tel...@gmail.com >>>>>>>> Skype: fabio_telles >>>>>>>> >>>>>>>> Timbira - A empresa brasileira de Postgres >>>>>>>> http://www.timbira.com.br >>>>>>>> >>>>>>>> Olá Fábio, >>>>>>> >>>>>>> Segundo meus graficos de monitoração zabbix, o iowait chega a 40% >>>>>>> nos momentos de lentidão. Certamente é o problema... >>>>>>> Essa máquina é uma VM e segundo as informações da gerencia VMWare, >>>>>>> essa máquina tem picos de 300 iops no momento de lentidão. >>>>>>> Como essa máquina é antiga, acredito que o BD foi projetado para um >>>>>>> tamanho e hoje esse limite foi alcançado, mas isso é puro "achismo!!!!" >>>>>>> por >>>>>>> isso preciso levantar mais informações sobre o postgres. >>>>>>> Vou analisar logs e posto se achar algo relevante. >>>>>>> >>>>>>> Obrigado, >>>>>>> >>>>>>> REnato >>>>>>> >>>>>> >>>>>> Renato, não sei exatamente como está seu ambiente aí, mas ao >>>>>> virtualizar um banco de dados, se não tiver pelo menos um disco dedicado >>>>>> aos dados desse banco, a concorrência de IO tende a ser muito mais lenta >>>>>> do >>>>>> que o normal. >>>>>> Um ideal mínimo te diria aí para vc separar discos, dando >>>>>> exclusividade para: >>>>>> >>>>>> - SO + VMs >>>>>> - PGDATA >>>>>> - pg_xlog >>>>>> >>>>>> []s >>>>>> >>>>>> >>>>>>> >>>>> O sistema está com partições separadas sim. >>>>> Olhei os arquivos e tem várias diretivas comentadas. >>>>> Existe algum comando para listar essas diretivas em execução ? >>>>> >>>> >>>> Infelizmente, em termos de performance apenas separar partições não >>>> adianta, pois fisicamente é a mesma cabeça de leitura / gravação. >>>> Discos != Partições >>>> Sobre que tipo de comando vc quer saber? >>>> >>> >>> Olá Juliano, >>> >>> Sim, o sistema está montado em discos diferentes. >>> Gostaria de saber como está a configuração atual do postgres. Tipo um >>> postconf do postfix, sabe ? >>> Quando dou o comando abaixo, vejo poucas linhas, ou seja, a maioria das >>> linhas estão comentadas no arquivo. >>> >>> # cat /etc/postgresql/8.3/main/postgresql.conf | grep -Ev "(#|^$)" >>> listen_addresses = 'localhost,XXX.XXXX.XXXX.XXXX' >>> datestyle = 'iso, mdy' >>> default_text_search_config = 'pg_catalog.english' >>> >>> Abraços, >>> >>> Renato >>> >> >> >> Boa Juliano, > > Era isso mesmo que queria. > Aproveitando... Qual dessas diretivas devo prestar mais atenção para > diagnosticar problemas de desempenho ? > > Abraços e muito obrigado, > > Renato > Por nada, Renato :) Cara... Na verdade são vários parâmetros de configuração do Postgres que impactam na performance. Alguns que lembro de cabeça agora: shared_buffers, checkpoint_segments, max_connections... É um assunto vasto que não tem receita de bolo. Existem até cursos específicos pra isso no PostgreSQL. Sugiro que se aprofunde mais no assunto pesquisando por "PostgreSQL Performance Tuning" []s > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
