Re: [pgbr-geral] Problemas de performance postgres
Em 12 de junho de 2013 23:53, Renato Sousa renso...@gmail.com escreveu: Boa noite a todos, Estou enfrentando alguns problemas de performance com um servidor que administro. Ao analisar o comando top, verifico 2 processos do postgres com 100% de uso direto: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 59968 pgsql 1 1010 74504K 27724K CPU22 0:27 100.00% postgres 59970 pgsql 1 1010 74504K 27016K CPU33 0:27 100.00% postgres Não conheço quase nada de postgres e gostaria de uma ajuda para tentar melhorar o desempenho desse servidor. O sistema operacional é FreeBSD 9, a versão do postgres é 8.4.13. FreeBSD 9 - XD PostgreSQL 8.4 - Já estamos no beta da versão 9.3 que será lançada em breve, com isso a versão 8.4 perderá o suporte. O PostgreSQL tem vários parâmetros de configuração em seu arquivo principal (postgresql.conf), sendo que várias delas afetam diretamente a performance do banco. Como pontapé inicial poderia nos informar o valor para shared_buffers? Lembrando que esse é só um dos... Outra coisa: recomendo fortemente que tenha um disco só para os dados (PGDATA) e outro só para os logs de transação (WAL), sendo que esse último não precisa ser um disco grande, mas rápido. Que tipo de partição vc está usando? UFS2? Se assim for, utilzar Soft Updates ajuda muito no desempenho de file system do FreeBSD. Abraços e muito obrigado, 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
Re: [pgbr-geral] Problemas de performance postgres
Boa tarde Juliano, A variável shared_buffers está com valor 32MB. Acredito ser a valor padrão de instalação. A partição está ligada com soft-updates, mas está tudo funcionando no mesmo disco. O servidor fica +/- 49% idle. O servidor tem 2G de RAM com CPU Intel(R) Xeon(TM) CPU 3.20GHz (3192.07-MHz K8-class CPU) A memória está quase toda ocupada (Mem: 499M Active, 907M Inact, 439M Wired, 67M Cache, 213M Buf, 55M Free) Milagre sei que não dá para fazer nesta máquina, mas preciso de alguma medida que me dê um folego para elaborar uma solução com mais calma. Abraços e muito obrigado! Renato Em 13 de junho de 2013 12:14, Juliano Atanazio juliano.l...@gmail.comescreveu: Em 12 de junho de 2013 23:53, Renato Sousa renso...@gmail.com escreveu: Boa noite a todos, Estou enfrentando alguns problemas de performance com um servidor que administro. Ao analisar o comando top, verifico 2 processos do postgres com 100% de uso direto: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 59968 pgsql 1 1010 74504K 27724K CPU22 0:27 100.00% postgres 59970 pgsql 1 1010 74504K 27016K CPU33 0:27 100.00% postgres Não conheço quase nada de postgres e gostaria de uma ajuda para tentar melhorar o desempenho desse servidor. O sistema operacional é FreeBSD 9, a versão do postgres é 8.4.13. FreeBSD 9 - XD PostgreSQL 8.4 - Já estamos no beta da versão 9.3 que será lançada em breve, com isso a versão 8.4 perderá o suporte. O PostgreSQL tem vários parâmetros de configuração em seu arquivo principal (postgresql.conf), sendo que várias delas afetam diretamente a performance do banco. Como pontapé inicial poderia nos informar o valor para shared_buffers? Lembrando que esse é só um dos... Outra coisa: recomendo fortemente que tenha um disco só para os dados (PGDATA) e outro só para os logs de transação (WAL), sendo que esse último não precisa ser um disco grande, mas rápido. Que tipo de partição vc está usando? UFS2? Se assim for, utilzar Soft Updates ajuda muito no desempenho de file system do FreeBSD. Abraços e muito obrigado, 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
Em 13 de junho de 2013 12:36, Renato Sousa renso...@gmail.com escreveu: Boa tarde Juliano, Boa tarde, Renato. Cara, um toque: evite top posting ;) A variável shared_buffers está com valor 32MB. Acredito ser a valor padrão de instalação. Vou reforçar minha recomendação: atualize seu Postgres! :) Mas para te atender no momento te recomendo fortemente que leia isto (doc v8.4): http://www.postgresql.org/docs/8.4/static/kernel-resources.html A partição está ligada com soft-updates, mas está tudo funcionando no mesmo disco. soft-updates - ok :) tudo funcionando no mesmo disco - :( Se puder separar os logs de transação por enquanto já ajudará, como te falei, não precisa ser um disco grande. Mas volto a falar, o mínimo seria um disco para instalação/SO, outro para PGDATA e outro para WAL. O servidor fica +/- 49% idle. O servidor tem 2G de RAM com CPU Intel(R) Xeon(TM) CPU 3.20GHz (3192.07-MHz K8-class CPU) A memória está quase toda ocupada (Mem: 499M Active, 907M Inact, 439M Wired, 67M Cache, 213M Buf, 55M Free) Milagre sei que não dá para fazer nesta máquina, mas preciso de alguma medida que me dê um folego para elaborar uma solução com mais calma. Esqueci de perguntar outra coisa, esse servidor é dedicado ao Postgres ou tem algum outro serviço rodando nele? Abraços e muito obrigado! Renato Em 13 de junho de 2013 12:14, Juliano Atanazio juliano.l...@gmail.comescreveu: Em 12 de junho de 2013 23:53, Renato Sousa renso...@gmail.com escreveu: Boa noite a todos, Estou enfrentando alguns problemas de performance com um servidor que administro. Ao analisar o comando top, verifico 2 processos do postgres com 100% de uso direto: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 59968 pgsql 1 1010 74504K 27724K CPU22 0:27 100.00% postgres 59970 pgsql 1 1010 74504K 27016K CPU33 0:27 100.00% postgres Não conheço quase nada de postgres e gostaria de uma ajuda para tentar melhorar o desempenho desse servidor. O sistema operacional é FreeBSD 9, a versão do postgres é 8.4.13. FreeBSD 9 - XD PostgreSQL 8.4 - Já estamos no beta da versão 9.3 que será lançada em breve, com isso a versão 8.4 perderá o suporte. O PostgreSQL tem vários parâmetros de configuração em seu arquivo principal (postgresql.conf), sendo que várias delas afetam diretamente a performance do banco. Como pontapé inicial poderia nos informar o valor para shared_buffers? Lembrando que esse é só um dos... Outra coisa: recomendo fortemente que tenha um disco só para os dados (PGDATA) e outro só para os logs de transação (WAL), sendo que esse último não precisa ser um disco grande, mas rápido. Que tipo de partição vc está usando? UFS2? Se assim for, utilzar Soft Updates ajuda muito no desempenho de file system do FreeBSD. Abraços e muito obrigado, 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 ___ 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
Re: [pgbr-geral] Problemas de performance postgres
Em 12 de junho de 2013 23:53, Renato Sousa renso...@gmail.com escreveu: Boa noite a todos, Estou enfrentando alguns problemas de performance com um servidor que administro. Ao analisar o comando top, verifico 2 processos do postgres com 100% de uso direto: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 59968 pgsql 1 1010 74504K 27724K CPU22 0:27 100.00% postgres 59970 pgsql 1 1010 74504K 27016K CPU33 0:27 100.00% postgres Não conheço quase nada de postgres e gostaria de uma ajuda para tentar melhorar o desempenho desse servidor. O sistema operacional é FreeBSD 9, a versão do postgres é 8.4.13. Inicialmente você deve identificar o que está causando o consumo de CPU, se por exemplo for um SELECT, é possível analisar a query e verificar se a mesma utiliza índices, outra coisa seria efetuar um bom tunning no seu server. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
Cara, um toque: evite top posting ;) Desculpe Juliano! Vou prestar mais atenção nisso :) A variável shared_buffers está com valor 32MB. Acredito ser a valor padrão de instalação. Vou reforçar minha recomendação: atualize seu Postgres! :) Mas para te atender no momento te recomendo fortemente que leia isto (doc v8.4): http://www.postgresql.org/docs/8.4/static/kernel-resources.html Vou estudar e já planejar a atualização do postgres! A partição está ligada com soft-updates, mas está tudo funcionando no mesmo disco. soft-updates - ok :) tudo funcionando no mesmo disco - :( Se puder separar os logs de transação por enquanto já ajudará, como te falei, não precisa ser um disco grande. Mas volto a falar, o mínimo seria um disco para instalação/SO, outro para PGDATA e outro para WAL. Aí é que mora o problema. Esse server foi instalado com uma partição só. Estou estudando colocar mais disco ou substituir a máquina, mas isso leva algum tempo para aprovação. O servidor fica +/- 49% idle. O servidor tem 2G de RAM com CPU Intel(R) Xeon(TM) CPU 3.20GHz (3192.07-MHz K8-class CPU) A memória está quase toda ocupada (Mem: 499M Active, 907M Inact, 439M Wired, 67M Cache, 213M Buf, 55M Free) Milagre sei que não dá para fazer nesta máquina, mas preciso de alguma medida que me dê um folego para elaborar uma solução com mais calma. Esqueci de perguntar outra coisa, esse servidor é dedicado ao Postgres ou tem algum outro serviço rodando nele? Tem sistema de email, apache, mysql, ou seja, é um faz tudo :( Abraços, Renato Abraços e muito obrigado! Renato Em 13 de junho de 2013 12:14, Juliano Atanazio juliano.l...@gmail.comescreveu: Em 12 de junho de 2013 23:53, Renato Sousa renso...@gmail.comescreveu: Boa noite a todos, Estou enfrentando alguns problemas de performance com um servidor que administro. Ao analisar o comando top, verifico 2 processos do postgres com 100% de uso direto: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 59968 pgsql 1 1010 74504K 27724K CPU22 0:27 100.00% postgres 59970 pgsql 1 1010 74504K 27016K CPU33 0:27 100.00% postgres Não conheço quase nada de postgres e gostaria de uma ajuda para tentar melhorar o desempenho desse servidor. O sistema operacional é FreeBSD 9, a versão do postgres é 8.4.13. FreeBSD 9 - XD PostgreSQL 8.4 - Já estamos no beta da versão 9.3 que será lançada em breve, com isso a versão 8.4 perderá o suporte. O PostgreSQL tem vários parâmetros de configuração em seu arquivo principal (postgresql.conf), sendo que várias delas afetam diretamente a performance do banco. Como pontapé inicial poderia nos informar o valor para shared_buffers? Lembrando que esse é só um dos... Outra coisa: recomendo fortemente que tenha um disco só para os dados (PGDATA) e outro só para os logs de transação (WAL), sendo que esse último não precisa ser um disco grande, mas rápido. Que tipo de partição vc está usando? UFS2? Se assim for, utilzar Soft Updates ajuda muito no desempenho de file system do FreeBSD. Abraços e muito obrigado, Renato ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
Em 13 de junho de 2013 14:20, Renato Sousa renso...@gmail.com escreveu: Cara, um toque: evite top posting ;) Desculpe Juliano! Vou prestar mais atenção nisso :) A variável shared_buffers está com valor 32MB. Acredito ser a valor padrão de instalação. Vou reforçar minha recomendação: atualize seu Postgres! :) Mas para te atender no momento te recomendo fortemente que leia isto (doc v8.4): http://www.postgresql.org/docs/8.4/static/kernel-resources.html Vou estudar e já planejar a atualização do postgres! Ótimo! :) A partição está ligada com soft-updates, mas está tudo funcionando no mesmo disco. soft-updates - ok :) tudo funcionando no mesmo disco - :( Se puder separar os logs de transação por enquanto já ajudará, como te falei, não precisa ser um disco grande. Mas volto a falar, o mínimo seria um disco para instalação/SO, outro para PGDATA e outro para WAL. Aí é que mora o problema. Esse server foi instalado com uma partição só. Estou estudando colocar mais disco ou substituir a máquina, mas isso leva algum tempo para aprovação. Sei que não é tarefa fácil negociar esse tipo de coisa com a diretoria, mas é preciso. O servidor fica +/- 49% idle. O servidor tem 2G de RAM com CPU Intel(R) Xeon(TM) CPU 3.20GHz (3192.07-MHz K8-class CPU) A memória está quase toda ocupada (Mem: 499M Active, 907M Inact, 439M Wired, 67M Cache, 213M Buf, 55M Free) Milagre sei que não dá para fazer nesta máquina, mas preciso de alguma medida que me dê um folego para elaborar uma solução com mais calma. Esqueci de perguntar outra coisa, esse servidor é dedicado ao Postgres ou tem algum outro serviço rodando nele? Tem sistema de email, apache, mysql, ou seja, é um faz tudo :( Então está bem claro que há uma competição por recursos da máquina. Mas vc pode usar esses serviços virtualizados. O FreeBSD possui virtualização em contêiner que consome poucos recursos, o Jails. Disputa dos serviços por CPU, memória e discos. Levando em conta que o maior desafio em termos de hardware para um banco são discos, ainda mais que no seu caso há outro, o MySQL, a necessidade de mais discos é latente. Abraços, Renato Abraços e muito obrigado! Renato Em 13 de junho de 2013 12:14, Juliano Atanazio juliano.l...@gmail.comescreveu: Em 12 de junho de 2013 23:53, Renato Sousa renso...@gmail.comescreveu: Boa noite a todos, Estou enfrentando alguns problemas de performance com um servidor que administro. Ao analisar o comando top, verifico 2 processos do postgres com 100% de uso direto: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 59968 pgsql 1 1010 74504K 27724K CPU22 0:27 100.00% postgres 59970 pgsql 1 1010 74504K 27016K CPU33 0:27 100.00% postgres Não conheço quase nada de postgres e gostaria de uma ajuda para tentar melhorar o desempenho desse servidor. O sistema operacional é FreeBSD 9, a versão do postgres é 8.4.13. FreeBSD 9 - XD PostgreSQL 8.4 - Já estamos no beta da versão 9.3 que será lançada em breve, com isso a versão 8.4 perderá o suporte. O PostgreSQL tem vários parâmetros de configuração em seu arquivo principal (postgresql.conf), sendo que várias delas afetam diretamente a performance do banco. Como pontapé inicial poderia nos informar o valor para shared_buffers? Lembrando que esse é só um dos... Outra coisa: recomendo fortemente que tenha um disco só para os dados (PGDATA) e outro só para os logs de transação (WAL), sendo que esse último não precisa ser um disco grande, mas rápido. Que tipo de partição vc está usando? UFS2? Se assim for, utilzar Soft Updates ajuda muito no desempenho de file system do FreeBSD. Abraços e muito obrigado, 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
Re: [pgbr-geral] Problemas de performance postgres
Desculpem-me... Faltou as informações do sistema: Debian 5 2 GB RAM postgres 8.3 free -m total used free sharedbuffers cached Mem: 3035 2905130 0 65 2702 -/+ buffers/cache:137 2898 Swap: 462 1461 top top - 10:28:50 up 28 days, 22:09, 5 users, load average: 0.21, 0.17, 0.16 Tasks: 142 total, 1 running, 140 sleeping, 0 stopped, 1 zombie Cpu(s): 0.7%us, 0.8%sy, 0.0%ni, 96.8%id, 1.7%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3108480k total, 2978144k used, 130336k free,67332k buffers Swap: 473876k total, 1144k used, 472732k free, 2767076k cached Abraços, Renato Em 27 de fevereiro de 2013 10:21, Renato Sousa renso...@gmail.comescreveu: 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. Como posso diagnosticar melhor a performance do postgres ? Abraços, Renato ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
Em 27 de fevereiro de 2013 10:21, Renato Sousa renso...@gmail.comescreveu: 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/~telles/shttp://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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
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.comescreveu: 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/~telles/shttp://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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
Em 27 de fevereiro de 2013 11:22, Renato Sousa renso...@gmail.comescreveu: 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.comescreveu: 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/shttp://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 ___ 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
Re: [pgbr-geral] Problemas de performance postgres
Em 27 de fevereiro de 2013 11:30, Juliano Atanazio juliano.l...@gmail.comescreveu: Em 27 de fevereiro de 2013 11:22, Renato Sousa renso...@gmail.comescreveu: 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.comescreveu: 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/shttp://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 ? Renato ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
Em 27 de fevereiro de 2013 12:06, Renato Sousa renso...@gmail.comescreveu: 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.comescreveu: 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.comescreveu: 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/shttp://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
Re: [pgbr-geral] Problemas de performance postgres
Em 27/02/13, Renato Sousarenso...@gmail.com escreveu: 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 ? Renato Você não informou qual arquivo está olhando e quais são as diretivas. Talvez o SHOW ALL possa auxiliar: http://www.postgresql.org/docs/current/interactive/sql-show.html Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
Em 27 de fevereiro de 2013 12:17, Juliano Atanazio juliano.l...@gmail.comescreveu: Em 27 de fevereiro de 2013 12:06, Renato Sousa renso...@gmail.comescreveu: 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.comescreveu: 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.comescreveu: 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/shttp://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...' datestyle = 'iso, mdy' default_text_search_config = 'pg_catalog.english' Abraços, Renato ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
Em 27 de fevereiro de 2013 14:23, Renato Sousa renso...@gmail.comescreveu: 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.comescreveu: 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.comescreveu: 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.comescreveu: 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/shttp://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...' datestyle = 'iso, mdy' default_text_search_config = 'pg_catalog.english' Abraços, Renato Que tal?: SELECT name||' = '||setting from pg_settings; ou diretamente no shell: psql -c SELECT name||' = '||setting from pg_settings; ___ 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
Re: [pgbr-geral] Problemas de performance postgres
Em 27 de fevereiro de 2013 14:35, Juliano Atanazio juliano.l...@gmail.comescreveu: Em 27 de fevereiro de 2013 14:23, Renato Sousa renso...@gmail.comescreveu: 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.comescreveu: 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.comescreveu: 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.comescreveu: 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/shttp://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...' 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas de performance postgres
Em 27 de fevereiro de 2013 15:19, Renato Sousa renso...@gmail.comescreveu: 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.comescreveu: 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.comescreveu: 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.comescreveu: 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.comescreveu: 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/shttp://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...' 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
