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

Responder a