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

Sex Mar 20 10:49:54 -03 2009

Seu problema pode estar no garbage colection x controle de transações.

Revise seu modelo trasacional para se certificar que não deixa 
transações abertas por muito tempo e veja como está o seu sweep interval 
no gstat.

Você pode começar experimentando desabilitar o sweep automático e 
colocá-lo para executar na madruga pelo agendador de tarefas, mas a 
chance maior é que você tenha problemas no controle transacional.

Eduardo

Denis escreveu:
> Oi Eduardo,
> 
> Hoje o banco de dados não é muito grande. Está em torno de 500 MB. O sistema 
> que acessa o banco de dados é feito em Delphi com 3 camadas. Então tenho 
> varias conexões acessando um servidor de aplicação, e este servidor de 
> aplicação acessando o FB. Ou seja umas 30 conexões por servidor de aplicação 
> (Total de 3 servidores de aplicação), acessando o banco de dados. Então 
> tenho apenas 3 conexões simultaneas no banco de dados, mas estas 3 conexões 
> acessando muito. ( creio que isto é um pool de conexões ).
> Por enquanto o estou usando o SuperServer, e parece que até está bem. Mas as 
> vezes fica lento, tipo umas engasgadas. Engraçado é que sempre a tarde fica 
> mais lento o sistema. Achei que pudesse ser alguma coisa de cache do 
> servidor, mas por diversas vezes no horário do almoço eu reiniciei tudo e 
> mesmo assim a tarde ficou mais lento. Estranho né. E os processos que 
> executam de manhã são os mesmos a tarde. Senão poderia ser alguma rotina que 
> estivesse carregando o servidor.
> Enfim, vou fazer alguns testes com o classic e ver o que dá.
> 
> Denis
> 
> 
> 
> "Eduardo Bahiense" 
> <eduardo em icontroller.com.br> escreveu na 
> mensagem news:gpue7a$ik3$1 em ger.gmane.org...
> 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
>>
>>
>> "Rodrigo A. de Freitas" 
>> <rodrigo em solucoeseinformatica.com.br> 
>> escreveu na mensagem 
>> news:46D24670810544058832E03D589AA8F4 em SOLUCOES.local...
>> Denis,
>>
>> Como o Cantu disse, o SuperServer não usa SMP então o parâmetro
>> CpuAffinityMask apenas diz qual núcleo do processador ele deve utilizar.
>>
>> No seu caso, você precisará instalar a Classic Server. A versão CS carrega
>> uma instância do FB_INET_SERVER para conexão feita ao banco de dados; 
>> assim,
>> o próprio sistema operacional se encarregará de balancear a carga dos
>> processos abertos pelas conexões entre os vários núcleos do processador.
>>
>> Um aviso: a versão CS é uma comedora de memória. Você precisará ter 
>> bastante
>> memória para que o servidor não fique sobrecarregado caso sua aplicação
>> tenha muitos usuários e/ou utilize várias conexões a base de dados, sem
>> contar os recursos do servidor que serão utilizados para outras 
>> aplicações,
>> caso a máquina não seja exclusiva para a base de dados.
>>
>> Eu tive problemas assim com um cliente, até que eles adquiriram um 
>> servidor
>> Dell exclusivamente para o BD. Instalaram um Linux Debian e nunca mais 
>> tive
>> problemas de performance.
>>
>> []'s
>>
>> Rodrigo A. de Freitas
>> Análise & Desenvolvimento
>>
>> Soluções & Informática
>>
>>
>>
>> -----Mensagem original-----
>> De: lista-bounces em firebase.com.br 
>> [mailto:lista-bounces em firebase.com.br] Em
>> nome de Carlos H. Cantu
>> Enviada em: quinta-feira, 19 de março de 2009 11:19
>> Para: FireBase
>> Assunto: Re: [firebase-br] Servidor FireBird + CpuAffinityMask = 3
>>
>> D> Então só para eu entender melhor. Significa que qualquer processador 
>> com
>> D> dois núcleos, o FB não vai usar inteiramente o processador, ou seja, 
>> não
>> D> compensa comprar uma máquina com dois núcleos no processador.
>>
>> Não. O SuperServer não usa SMP (CpuAffinity é um parâmetro do
>> SuperServer). A versão Classic utiliza quantos processadores estiverem
>> disponíveis. Procure nas mensagens antigas da lista para saber mais.
>>
>> []s
>> Carlos H. Cantu
>> www.FireBase.com.br - www.firebirdnews.org
>> www.warmboot.com.br - blog.firebase.com.br
>>
>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>> http://www.firebase.com.br/fb/artigo.php?id=1107
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.0.238 / Virus Database: 270.11.19/2011 - Release Date: 03/19/09
>> 07:05:00
>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para saber como gerenciar/excluir seu cadastro na lista, use: 
>> http://www.firebase.com.br/fb/artigo.php?id=1107
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para saber como gerenciar/excluir seu cadastro na lista, use: 
>> http://www.firebase.com.br/fb/artigo.php?id=1107
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: 
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa