Olá, pessoal To chegando atrasado para a discussão mas eu queria participar.
Você tem habilitado o log do PostgreSQL? Se sim, tem alguma informação nele? Você percebeu se consultas anteriormente rápidas passaram a ficar extremamente lentas? Se o seu log de atividades do PostgreSQL não está habilitado eu iria sugerir você habilitar os seguintes parâmetros. redirect_stderr = on log_min_duration_statement = 1s log_line_prefix = '%t [%p]: [%l-1] ' - permite a leitura dos logs pelo pgFouine, conforme o Guedes comentou. Assim, como o Guedes comentou seria interessante você analisar o período de quanto em quanto tempo ocorreu o checkpoint. O padrão é de 5 em 5 minutos, ou a cada 48MB, isto porque, checkpoint_segments=3*16 que é o tamanho de cada segmento. Se você tivesse trabalhando com a versão 8.3 você poderia habilitar o parâmetro log_checkpoints = on, que ele mostraria as informações de cada ocorrência de checkpoint. Outra dúvida é que não vi ninguem comentar. Vocè tem algum processo de analyze rodando diariamente. Eu vi que você falou que nenhum restore ou vacuum resolve, mas você não comentou nada sobre vacuum ou autovacuum. Você faz uso de algum destes procedimentos de manutenção? Outro detalhe, você ou alguem mais realizou alguma configuração no arquivo de configuração do PostgreSQL? Lembro de ter visto você comentado sobre conexões em idle ou idle transaction. As conexões em idle transaction ficam muito tempo penduradas? Será que você não ta ficando com alguma transação em aberto que esteja bloqueando alguma coisa? Seu banco cresceu nos últimos dias? Ou teve algum processo de carga que tenha aumentado o volume de dados de alguma tabela e isso possa estar impactando por derrepente algum atributo que não era consultado e agora esta sendo bastante consultado e não tem um índice por exemplo? Tem a questão dos discos, se o disco tiver problema certamente você terá sua problema global prejudicada. Outra dúvida, é só o PostgreSQL que está lento ou toda a máquina esta lenta? 2009/11/26 Tiago Adami <[email protected]> > 2009/11/26 Dickson S. Guedes <[email protected]>: > >> 2009/11/26 Tiago Adami <[email protected]> > >>> > >>> 2009/11/26 Dickson S. Guedes <[email protected]>: > >>> > 2009/11/26 Tiago Adami <[email protected]>: > >>> >> Já investigamos a causa da lentidão antes. Aparentemente não há nada > >>> >> de incomum, apenas a velocidade para consultas simples (cadastros de > >>> >> itens, por exemplo) torna-se baixa e tarefas como gravação de nota > >>> >> fiscal que levavam segundos passam a demorar minutos. > >>> > > >>> > Você tem um histórico do tempo que tem levado para que os CHECKPOINTs > >>> > sejam executados? > >>> > > >>> > >>> Como visualizo isso? > > > > Nos logs é um bom começo. Mas você precisa logar esta informação, > > basta habilitar no postgresql.conf [1]. É bom ter uma noção porque > > enquanto o banco está fazendo um checkpoint seu desempenho cai. > > > > Ok, vou verificar. > > >>> > Você tem um histórico de como está a utilização de disco quanto à > >>> > entrada e saida? O I/O pode ser uma das causas. > >>> > > >>> > >>> Há como ler um histórico de I/O do banco? Esta informação fica > armazenada? > > > > Ao menos nos discos sim, no banco voce tem várias informações que > > podem ser obtidas com os dados das tabelas pg_stats_*. Um CACTI com um > > plugin check_postgresql.pl do nagios [2] por exemplo pode ter dar boas > > informações de historico destes dados. Além disto, no caso do Windows > > existem ferramentas de tempo real que você consegue visualizar esta > > utilização. > > > > Também vou verificar com mais tempo... > > > > >>> >> (...) > >>> >> ... o array dos dois discos que contém o banco possui pastas > >>> >> compartilhadas sim, e com muitos arquivos nela. > >>> > > >>> > O que são "muitos arquivos" ? Há problemas quanto há muitos arquivos > >>> > (~1k) em um único diretório num NTFS. > >>> > >>> Imagine uma pasta onde todos e qualquer um podem gravar arquivos, > >>> desde planilhas do Excel, relatórios emitidos pelo sistema em TXT, > >>> MP3. Mas pelo o que observei, o movimento nestas pastas é bem pequeno. > > > > Quantos arquivos existem? Já tive problemas em Windows 2003 com NTFS > > em um cliente onde foi necessários dividir uma única pasta em 256 > > pastas distintas cada uma com 16 subpastas, distribuindo então os > > arquivos entre elas. > > > > A quantidade não importa muito, ainda não contei os arquivos. Fato é > que no caso deste cliente, o servidor deve ser dedicado. Se rodar > Windows, pelo menos o disco deve ser dedicado. O difícil é colocar > isso na cabeça dos clientes, sempre querem baixo custo e alto > desempenho. Fato é que, também, praticamente todos os nossos clientes > mantém compartilhamentos no mesmo disco onde está instalado o > PostgreSQL, pois eles _acham_ que por ser um servidor, deve guardar > tudo. > Outro detalhe é que sempre rodou assim antes, e nunca deu estes > problemas. Vou tentar banir os compartilhamentos, mas será uma tarefa > árdua. > > >>> > >>> >> Enfim... o jeito é fazer benchmarks próprios para verificar o > >>> >> desempenho entre os dois SO. Uma vantagem que visualizo com a troca > >>> >> para Linux é que não existirá muita coisa rodando como serviço, > coisa > >>> >> que infelizmente o Windows possui desde a sua concepção. > >>> > > >>> > Faça os benchmarks e se possível publique-os para referências > futuras. > >>> > >>> Posso fazer sim, sem problemas, mas terei que usar parâmetros da nossa > >>> aplicação. > > > > Também pode ser interessante logar as consultas que demoram mais que > > um certo tempo (~100ms por exemplo?) e analisá-las com um pgfouine > > por exemplo, pois podem ser consultas que não se dão muito bem em > > ambientes muito concorridos. > > > > Já implementamos um "logging" na aplicação em todos os comandos SQL > que são executados, e as primeiras modificações já começaram a ser > feitas em comandos SQL pouco eficientes. > > > [1] > http://www.postgresql.org/docs/8.2/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS > > [2] http://bucardo.org/check_postgres/ > > > > []s > > Dickson S. Guedes > > mail/xmpp: [email protected] - skype: guediz > > http://guedesoft.net - http://www.postgresql.org.br > > -- > TIAGO J. ADAMI > http://www.adamiworks.com > _______________________________________________ > 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
