> 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. >> > 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. >> >> (...) >> >> ... 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. >> >> >> 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. [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 _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
