Exatamente o ponto que eu queria abordar - equilibrio - não adianta se preocupar tanto com o poder de processamento se tu não equilibrar bem as coisas, certos garagalos se formam ai jaz viu é o BD que vai levar a "sapecada".
Sei disso pois como DBA ja peguei muito engenheiro de sistema que se baseou num hardware com multiprocessamento destrutivo mas ligado numa simples controladora RAID-0 com 1gb memória para um banco de 20gb e jogou a culpa no SGBD. Depois de muito estudo uma controladora dedicada em RAID-5 usando o mesmo processador e 4gb de memória depois, a coisa ficou melhor.
No caso do colega se tiver um RISC bem equilibrado não vai haver problema nenhum no meu entendimento.
Sei disso pois como DBA ja peguei muito engenheiro de sistema que se baseou num hardware com multiprocessamento destrutivo mas ligado numa simples controladora RAID-0 com 1gb memória para um banco de 20gb e jogou a culpa no SGBD. Depois de muito estudo uma controladora dedicada em RAID-5 usando o mesmo processador e 4gb de memória depois, a coisa ficou melhor.
No caso do colega se tiver um RISC bem equilibrado não vai haver problema nenhum no meu entendimento.
----- Mensagem Original -----Data: Segunda, 22 De Setembro De 2008 22:11Assunto: Re: [pgbr-geral] RES: benchmark postgres risc vs outros
Em Mon, 22 Sep 2008 17:46:16 -0300
"Jeanderson Machado" <[EMAIL PROTECTED]>escreveu:
> O que pesa mais em termos de servidores para o postgres é mesmo o
> aray de discos, quanto mais melhor, o segundo critério é a memória
> para depois chegarmos no processador, não adianta em muito ter um
> processador potente se ligarmos num simples arranjo de discos. Pelo
> menos é essa conclusão que chegamos em nossos testes e em vários
> tópicos de discussão que acompanha na web.
[...]
Você tem razão pela estratégia de discos mas...
...Se olharmos os benchmarks (pelo menos por enquanto) de TPC[1] ou
SpecJ[2], a maioria está usando servidores com processadores RISC e
a grande questão é como gastar para ter melhor equilíbrio de
infra-estrutura (Armazenamento, Rede, Processamento, etc.), garantindo
melhor *taxa de transferência* de dados (Throughput). Creio que o
melhor é o que Euler[3] comentou sobre qual critério adotar.
No wiki do PostgreSQL tem uma boa documentação sobre performance[4]
que o pessoal está escrevendo. Uma delas aponta para um texto[5] do
Bruce
Momjian sobre performance tuning e hardware que apesar de 2003, ainda é
bem atual. :)
Referências:
1- http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
2- http://www.spec.org/jAppServer2004/results/jAppServer2004.html
3-
http://listas.postgresql.org.br/pipermail/pgbr-geral/2008-September/011849.html
4- http://wiki.postgresql.org/wiki/Performance_Optimization
5-
http://www.postgresql.org/files/documentation/books/aw_pgsql/hw_performance/
[]'s
--
Fernando Ike
http://www.midstorm.org/~fike/weblog
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
