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? > > Renato > > > _______________________________________________ > 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
