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
