Marcelo Corrêa - CHB Sistemas escreveu:
> Não necessariamente, suas sentenças podem estar mal formadas também, seus 
> índices podem estar fragmentados, pode-se se fazer necessário uma repaginação 
> no BD. E por ai vai ... pode ser uma serie de coisas relacionadas ao BD tbm 
> !!!
>   
Estou ciente disso e citei isso nos meus primeiros e-mail sobre esse 
assunto que passei para lista.

> Seus testes devem ser realizados apenas no servidor em produção, dessa forma 
> que vc fez não tem como analisar o problema, pois são ambientes diferentes.
>
>   
A idéia foi comparar a performance de um programa que utiliza somente 
CPU e memória em hardwares diferentes, o que comprovou que no cliente o 
processamento é bem mais lento.

> Att,
> Marcelo Corrêa.
> MCPDBA - OCP
>   ----- Original Message ----- 
>   From: Marlon David de Souza 
>   To: Comunidade PostgreSQL Brasileira 
>   Sent: Friday, November 21, 2008 1:51 PM
>   Subject: Re: [pgbr-geral] Problema em rodar num Linux uma versão não 
> homologado do Postgres
>
>
>   Fernando Ike escreveu: 
> 2008/11/21 Marlon David de Souza <[EMAIL PROTECTED]>:
> [...]
>   Para ter certeza que o problema não está no PostgreSQL, utilizamos um
> software que monta em memória uma lista com cerca de 30MB e a ordena,
> mostrando o tempo necessário para essa tarefa. Esse programa gera um
> processo que somente utiliza a memória e a CPU. Colocamos ele para rodar no
> servidor do cliente e também em algumas outros servidores e obtivemos os
> seguintes resultados (tempo execução):
>
> - Core 2 Duo, 1.8GHz, 2MB de cache:              3m43s
> - Xeon (2 núcleos), 2.4GHz, 4MB de cache:        2m32s
> - Pentium 4, 3GHz, 2MB de cache:                 4m08s
> - Celeron, 1.8GHz, 128Kb de cache:               5m29s
> - Core 2 Quad, 3GHz, 8MB de cache:               1m50s
> - Xeon (2 núcleos), 3.2GHz, 2MB de cache:        5m24s <--- Servidor do
> cliente
>     
>
>     Seu problema não é exatamente o processador, ele é um ponto no
> problema mas a diferença demonstrada aí está relacionada no cache L2,
> é pequeno mas quanto maior o L2 mais rápido os bancos de dados rodarão
> (AMD64/EMT64). Tem outras coisas como barramento, etc.
>
>    Superficialmente parece que você está certo, como está com o
> ambiente nas mãos pode afirmar melhor do que nós. ;)
>
>
> []'s
>   Não se trata se eu estou certo ou não. A questão é que o cliente insiste 
> que o problema está no PostgreSQL e eu estou tentando provar para ele que 
> não. O que limita a performance das consultas é arquitetura do hardware (CPU, 
> memória, barramento, cache, etc).
>
>   
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a