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

Eduardo Bahiense eduardo em icontroller.com.br
Ter Out 28 09:55:52 -03 2008


Olá Valdir

Show! Esclareceu bastante. Esta semana iremos implantar o novo ambiente 
e devemos realmente partir para o SS em duas instâncias sem forçar 
CPUAffintiy.

Como é um ambiente centralizado, com todos os 300 clientes acessando o 
mesmo conjunto de servidores, e, sendo a instalação do FB um processo 
rápido, acredito que poderemos, com monitoramento intenso, cambiar entre 
uma ou outra configuração com facilidade, se for o caso. Como temos 
métricas do Classic por quase três anos, ficará igualmente fácil 
identificar as diferenças do ambiente com o SuperServer.

Esse tipo de análise é muito importante para nós, pois mantemos o 
serviço em datacenter e o custo de servidores dedicados no Brasil, 
embora já mais acessíveis, não permite desperdício, e, sendo o SAAS 
(Software as Service) ainda uma novidade, performance e estabilidade são 
essenciais para se manter a confiança daqueles que logo perguntam: "mas 
meus dados ficarão fora da minha empresa?"

Muito bom saber que temos profisionais como o Tosi, Você, o próprio 
Cantu e tantos outros, que poderemos contar para uma consultoria mais 
especializada conforme tivermos que escalonar para ambientes de maior 
concorrência.

Obrigado mesmo, a Você, ao Tosi e ao Cantu.


Essa lista é fantástica!


Eduardo

Valdir Marcos escreveu:
> 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
>>
> ______________________________________________
> 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
> 





Mais detalhes sobre a lista de discussão lista