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

[Valdir Marcos]

Bom dia.

Dizem que toda generalização é burra, incluindo esta... mas, uma instalação
básica do Firebird SuperServer, em um Linux básico, com uma aplicação
cliente/servidor bem feita (com um bom controle transacional, sem
commitretaining, sem  BDE com autocommit) para até 50 usuários, e em um
hardware bom - com mais de um núcleo, com 2GB de ram e HD SATA - terá ótima
performance para a maioria dos casos onde existe um fdb de até 4GB.
Entretanto, quando se estoura esses limites ou se deseja ter um ambiente
preparado aguentar futuras demandas bem maiores, faz necessário ajustes
detalhados. É preciso rever e ajustar todo o conjunto, não apenas mexer no
Firebird, Windows ou Linux.

Tentarei não ser técnico ou teórico demais.
Não é que o Linux não precise do CPU AFFINITY, nem que o Linux não tenha
troca de processos entre núcleos ou processadores de um servidor, mas isso
deve ser aplicado com cautela e em casos muito específicos, como aquele em
que o Oracle cobra por núcleo/processador e sua nova máquina tem oito 8
processadores... he he he
A partir do kernel 2.5 (e patches retroativos) ficou muito fácil tornar uma
aplicação em C++ amarrada a um determinado processador, basta usar a função
sched_set_affinity(). Teoricamente, qualquer um poderia ter um Firebird
personalizado com essa característica, bastaria alterar e recompilar o
código fonte. Quando não fosse possível alterar o código fonte, poderia-se
usar o comando "bind", entre outros similares, para fazer esse serviço.
Todavia, cabe a análise: sendo isso tão simples, porque os desenvolvedores
do Firebird não o fizeram?... ou porque fizeram esse recurso apenas para o
Windows?
O kernel do Linux é muito inteligente para lidar com balanço de cargo entre
processadores, memória (RAM e discos), processos e threads mesmo e
principalmente com aplicações antigas que não possuem tratamento interno
para SMP, como acontece com o Firebird.
Como exemplo e exercício empírico bem simples, considerando o Firebird
SuperServer (que é mais simples de cuidar, porém menos escalável) instalado
numa máquina básica de dois núcleos só para cuidar do banco de dados, no
horário de pico da sua aplicação, vá no terminal do seu servidor Linux e dê
um top, depois digite 1 para exibir a distribuição de carga entre os
processadores. Você verá que o processador 0 cuida da maioria dos processos
do Linux (que consomem menos de um porcento em ambiente somente texto) e o
fbserver consumindo recursos, na maior parte do tempo, no núcelo 1. De vez
em quando, você verá o fbserver consumindo um pouco de recurso do núcleo 0,
tipo 27% em 1 e 3% em 0... o Linux tenta manter, dentro do possível, todas
as threads do fbserver que precisam de informações do cache no mesmo
processador (pela vantagens que o Douglas Tosi mencionou no email anterior)
e joga o que não precisar no outro cache para balancear a carga. Para
aqueles que conseguirem ver o núcleo 1 dando picos de 100% por causa do
Firebird, verão que depois disso o processamento no núcleo 0 começa a
subir... Além disso, o Linux joga tudo que pode na RAM para dar mais
performance, tenha certeza que se seu fdb for menor do que a RAM, existe boa
chance dele estar inteiro nela... como um caso contado outro dia aqui na
lista onde o arquivo físico foi apagado do disco e recuperado via restore
diretamente da RAM... para não esticar demais não falarei sobre como o Linux
gerencia a RAM e os discos.

Eduardo, minha sugestão, assim como a da maioria dos consultores que
respondem nessa lista, é que você faça testes. Dentro do possível, deixe um
tempo no Windows 2003, no 2008, no Linux e em cada SO, use alguns dia o
Firebird Classic, depois alguns dias no Firebird SuperServer, antes de
fechar definitivamente com algum SO e versão do FB.

E respondendo sua pergunta inicial "E se colocássemos duas instâncias do
SuperServer, uma em cada porta, poderíamos usar o cpu afinity para que cada
um usasse um núcleo?" Se você colocar dois ou três FB SS (já que você tem 3
fbds) no Linux, o próprio kernel fará o balanço de carga sem você precisar
mexer no CPU AFFINITY.

Como você usa pool de conexões (via FastCGI) e tem um excelente controle
transacional, faça testes com o FB SS e você poderá ter boas surpresas.

Se sua empresa concordar e puder pagar, procure uma boa consultoria para
fazer o ajuste fino (tunning)

Eu tive o prazer de conhecer o Douglas Tosi pessoalmente no final do 5o FDD
e dá para se aprender muita coisa conversando com ele.

Um abraço,

Valdir



Em 27/10/08, Douglas Tosi <douglasht em gmail.com> escreveu:
>
> 2008/10/27 Eduardo Bahiense <eduardo em icontroller.com.br>:
> >> Se me lembro bem, a configuração de affinity foi incluída na
> >> configuração do FB para windows para facilitar. Muita gente estava
> >> usando ferramentas externas para isto, porque o esquema usado pelo
> >> kernel do windows para distribuir a carga entre as cpus não favorecia
> >> o firebird SS. Mas você não é *obrigado* a colocar um affinity para o
> >> SS.
> >> Talvez por isto a configuração nem exista no linux.
> >
> > Oi Douglas, não entendi. Partindo da idéia original, trabalhar com duas
> > instancias do SuperServer, uma em cada porta, como posso garantir que uma
> > usará um núcleo e a outra o segundo, sem forçar um cpuaffinity?
>
> Você não precisa forçar o cpu affinity para isso acontecer. O sistema
> operacional faz isso.
>
> O affinity só server para garantir que o SS, que na prática funciona
> como se só tivesse um thread de execução, não fique pulando de uma cpu
> para outra durante a execução. Esse pula-pula causa trocas de contexto
> (context switches) desnecessários e atrapalha a performance (pelo
> menos em teoria, porque eu nunca vi um benchmark com affinity e sem
> affinity dar diferente).
> Já o kernel do linux (novamente, se me lembro bem) não causa esse
> pula-pula, por isso não precisa do affinity.
>
> Resumo da ópera: Linux não precisa de affinity. No windows ele é
> recomendado, mas não é obrigatório (tanto que IB6 e anteriores não
> vinham com ele de fábrica).
> Se você vai rodar linux, pode colocar dois SS e esqueça do affinity.
> Eles vão usar suas duas CPUs sim (exceto se tiver algum affinity
> escondido, aí por favor os gurus em linux pulem aqui e me corrijam).
>
> melhorou? ou acabei de piorar? :)
> --
> Douglas Tosi
> www.sinatica.com
>
> ______________________________________________
> 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
>