[firebase-br] Super Server e dois núcleos

[Carlos H. Cantu]

A lentidão pode estar sendo causada pelo sweep automático. Se for
isso, desligue-o e agenda um sweep manual de madrugada.

Quanto a mudança para o SS, o correto seria vc testar e ver na prática
se a diferença justifica a mudança, pois há muitas variáveis
envolvidas. Vale o ditado: Teste antes, pra não se arrepender depois
;)


[]s
Carlos H. Cantu
www.warmboot.com.br - www.firebirdnews.org
www.FireBase.com.br - blog.firebase.com.br

EB> Boa noite senhores


EB> Temos hoje nosso servidor de aplicação no mesmo computador do servidor
EB> de dados. Por questão de escalonamento, estamos abrindo um servidor só
EB> pro FB, ou seja um servidor exclusivo de dados, que só terá o FB 
EB> gerenciando 3 bancos de dados, 1 de 3GB em um HD e outros dois de +- 1GB
EB> cada, em outro HD. Esperamos com isso ter uma folga de hard por um bom
EB> tempo.

EB> Neste cenário, temos 5 processos fastcgi acessando esses 3 bancos, a 
EB> partir de um servidor de login que diz em que base estão os dados do 
EB> cliente logado. Assim, durante a operação normal, levantam-se até 15 
EB> instâncias do Classic, com uma média de 350 - 500 terminais logados 
EB> simultaneamente, servidos por esses 5 fastcgi's.

EB> Até agora, um único server deu conta, mas já começamos a experimentar 
EB> lentidão em alguns horários de pico. O controle transacional, ao que 
EB> parece, pela análise do gstat, está perfeita.

EB> Com esse movimento, esperamos escalonar distribuindo processamento, uso
EB> de memória e acesso a disco.

EB> A dúvida que nos surgiu foi a seguinte:

EB> Até agora, usamos o Classic por duas razões:

EB> 1. Se tivéssemos problema em uma conexão, seria fácil matar um processo
EB> e não afetar os demais.
EB> 2. O Classic usa os dois núcleos do procesador.

EB> Quanto à primeira, em 3 anos de operação, já temos confiança suficiente,
EB> o cara é "bão mesmo", não trava (claro que ficamos "mais bãos" também 
EB> durante o tempo, corrigindo um monte de queries mau construídas).

EB> Quanto à segunda, um membro de nossa equipe fez a seguinte pergunta:
EB> *E se colocássemos duas instâncias do SuperServer, uma em cada porta, 
EB> poderíamos usar o cpu afinity para que cada um usasse um núcleo?*

EB> Bem, isso porque, com 15 instâncias gerenciando 3 bases que guardam 
EB> dados de +-300 clientes, o overhead de memória ao longo do dia é grande
EB> com o cache do classic, mas como fazemos backup duas vezes por dia, esse
EB> cache é zerado no início da manhã e final da tarde.

EB> Assim, resolvi submeter isso aos ilustres gurus e ver se alguém me ajuda
EB> a decidir isso antes de instalar o novo servidor.


EB> Abraço a todos


EB> Eduardo


EB> ______________________________________________
EB> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
EB> Para saber como gerenciar/excluir seu cadastro na lista, use:
EB> http://www.firebase.com.br/fb/artigo.php?id=1107
EB> Para consultar mensagens antigas: http://firebase.com.br/pesquisa