[firebase-br] RES: Servidor FireBird + CpuAffinityMask = 3

[Eduardo Jedliczka]

Concordo com o Eduardo Bahiense... na maioria das vezes o Superserver apresenta performance melhor que o Classic numa máquina single-core (100% das vezes) ou dual-core (em boa parte das vezes), principalmente se o seu banco inteiro couber na RAM do computador (onde a quantidade de acessos de leitura é drasticamente reduzida, mas não a quantidade de gravações).

O Classic é insuperável quando se tem 6 ou mais núcleos, e pelo menos 8
gb de ram. 

Mas duas coisas que impactam absurdamente o desempenho do banco (e
poucos dão atenção) é Velocidade do HD e quantidade de RAM.

Para tirar dúvidas, resolvi comparar um Servidor de médio custo, com um
Desktop top-de-linha, com o FB Classic - banco de 6 gb, com aprox. 100
conexões concorrentes (Ambos com UBUNTU Server 8.04 com kernel SMP).

Desktop:  Core 2 Quad 3.16ghz com 4 gb de ram (2x2 gb Geil DDR2 800 CAS
4) e 2 HDs SATA 500gb de 7200rpm em Raid (stripping)
Servidor Dell: 1x Xeon-Dual Core 2.4 com 4 gb de ram (4x1gb FBDIMM 800),
controladora SAS com 256mb de cache e dois discos 2.5" 146gb de 15.000
rpm em Raid (mirroring) 

OK. o Dell é um servidor, com processador XEON (que perde em qualquer
benchmark para o C2Q 3.16 de 8 mb de cache) que custava o dobro do preço
do desktop.

Resultado: o DELL ESPANCOU, HUMILHOU, DESTROÇOU o Desktop. - Num restore
então, o XEON gastava menos de 5 minutos enquanto que o desktop
precisava de mais de 20min!!!!

então, o que causou a diferença ? a qualidade das memórias (que possuem
cache interna em todos os pentes) e a brutal diferença de desempenho dos
discos (e da controladora SAS né). 

Ou seja, processador interfere (naturalmente interfere e muito)... mas
muitas vezes um processador rápido fica no aguardo de dados que estão em
disco. Se eu tivesse pelo menos 8 gb de ram, o desempenho começaria a
favorecer o C2Q. 

Porém, com12 GB de Ram (meu desktop não aceita tudo isto, e o server
aceitava módicos 8 pentes de 2 gb) aposto que o C2Q levava o troféu
(exceto no restore).

Ou seja, pense muito sobre a configuração do equipamento que você
pretende adotar, veja quantos usuários serão atendidos... Muitos
reclamam da performance do FB, mas não querem gastar 5 ou 6 mil com
servidor (que é Quase o que duas licenças ENTERPRISE do M$ SQL SERVER).

PS: Também fiz testes com um Dual Xeon-Quad Core 2.2 com 16gb de ram
(8x2gb) e 4 discos de 300gb de 15k rpm em Raid 0+1 (valor de mercado de
mais de 20 mil reais), mas aqui já é covardia... nunca vi mais do que 6
núcleos usarem 100%, mesmo com mais de 300 conexões concorrentes (e uma
base de 16 gb)

Mas, falando do superserver e classic, se você tem 2gb ou menos de Ram e
um processador c2q, deixe o próprio SO fazer cache do banco e usar o
segundo núcleo para ele, pois nos processadores da Intel para desktop, a
cache L2 é compartilhada (assim como o barramento) pelos dois núcleos, o
que faz que o SS aproveite bem o conjunto.

Sem mais,

Eduardo Jedliczka
Universidade Tecnológica Federal do Paraná
Campus Apucarana

Em Qui, 2009-03-19 às 18:41 -0300, Eduardo Bahiense escreveu: 
> Olá Denis
> 
> Deixa eu te passar um pouco da minha exepriência neste assunto:
> 
> A decisão de optar entre o classic e o superserver vai um pouco além dos 
> núcleos.
> Mesmo que esse servidor seja dedicado apenas ao FB, ele roda outros 
> processos do Sistema Operacional, assim, se você tem dois núcleos, 
> quando o núcleo que o FB usa estiver ocupado, o próprio S.O. desviará os 
> outros processos para o núcleo mais livre, e isso, na prática, será quae 
> como se o FB usasse os dois.
> 
> Quando você fala em Classic, você está falando em uma instância do FB 
> para cada conexão, a menos que você trabalhe com pool de conexões. Em 
> nosso caso, que trabalhamos com pool de 15 conexões, a diferença de uso 
> de memória foi brutal entre o classic e o superserver (hoje usamos o 
> superserver), com 4GB de RAM, gerenciando 3 bancos volumosos, tínhamos 
> sempre a memória toda utilizada, claro que a maior parte da memória 
> utilizada era em chache do linux, que mais otimiza do que atrapalha, com 
> o Superserver, hoje em um server de 8GB, temos sempre em torno de 5 GB 
> livres (que desperdíco, não?).
> 
> Assim, eu acho que poderíamos resumir da seguinte forma:
> 
> 1. Você usa pool de conexões ? -> Classic é uma opção
> 2. A quantidade de conexões simultâneas é baixa -> Classic é uma opção
> 3. A quantidade de conexões simultâneas é alta, mas os BDs são pequenos 
> ou o volume de transações é pequeno-> Classic é uma opção
> 4. Os Bds são muito grandes ou a quantidade de conexões é muto grande ou 
> o volume de transações é muito grande, com 4GB eu optaria pelo Superserver

> Eduardo
> 
> Denis escreveu:
> > Olá,
> > 
> > A Maquina que está o banco de dados é um Dell Xeon E3113 com 4GB de memória 
> > e HD SAS, com Windows Server 2003 R2. Como política da empresa e até minha, 
> > não entra nenhum software ilegal aqui. Nem para teste. Creio que não terei 
> > problemas então, se colocar a versão classic. Outra coisa, esta máquina vai 
> > ser usada exclusivamente para banco de dados, mais nada.
> > Vou deixar rodando um pouco mais o banco de dados com a versão SuperServer e 
> > depois vou colocar a Classic para ver qual se comportará melhor. Aí a que se 
> > adaptar melhor eu deixo ela funcionando.
> > 
> > Denis