Configurações do Firebird

Firebird – SuperServer, ClassicServer ou SuperClassic?

SuperServer

No SuperServer existe apenas um cache de páginas que é compartilhado por todas as conexões.

Por ser compartilhado, este cache é muito eficiente. Quando vários clientes acessam as mesmas
áreas do banco de dados ou quando algumas tabelas são muito mais acessadas que outras, todos os
clientes se beneficiam de um cache grande e bem preenchido.

Por exemplo, quando o cliente A executa:

SELECT NOME FROM CLIENTES WHERE CODIGO = 1

Algumas páginas relacionadas a tabela CLIENTES e ao índice da chave primária CODIGO são
carregados para o cache.

Quando o cliente B executa:

SELECT NOME, ENDERECO, TELEFONE FROM CLIENTES WHERE CODIGO = 2

Ele se beneficia do cache compartilhado porque as

páginas que este comando precisa já estão no
cache.

Note também que existe apenas um único processo

onde todos os clientes se conectam.

Veja no diagrama:

O SuperServer sofre de problemas de

escalabilidade. Se você instalá-lo num computador
com mais de uma CPU (o que é bem provável hoje
em dia) ele vai usar apenas uma delas. Isto não é
problema para instalações pequenas ou ambientes
onde o servidor terá outras atividades além do banco
de dados.
1: Diagrama Super Server
Por exemplo, você tem um servidor dual-core e quer
usá-lo como servidor de arquivos, web, impressão e
banco de dados. Não é problema que o Firebird use apenas uma CPU porque o servidor terá outras
atividades para ocupar a outra CPU. E você ainda terá o benefício de usar um banco de dados leve e
ágil, que consome poucos recursos do servidor.

Mas para operações grandes, em que você quer que o banco de dados aproveite cada ciclo das
CPUs do servidor, o SuperServer pode ser frustrante.

Exceto se você tiver mais de um banco de dados. A partir do Firebird 2.5, o SuperServer consegue
usar mais de uma CPU desta maneira. Uma para cada banco de dados. Se você tiver apenas um
banco de dados o limite ainda se aplica.
ClassicServer

No ClassicServer, cada cliente tem um cache próprio e está conectado a um processo dedicado.

O cache dedicado é muito menos eficiente. Se dois clientes acessam a mesma área do banco de
dados, esta área será copiada no cache de cada um deles. Usando o exemplo anterior, quando o
cliente B executasse seu comando, ele não teria o benefício de um cache já preenchido e o Firebird
precisaria acessar o disco novamente para
responder. Além do mais, a sincronização entre os
caches é feita através do disco. Isto aumenta
consideravelmente o custo de I/O para ambientes
de alta concorrência.

Veja no diagrama:

Um grande benefício deste modelo é a resiliência

oferecida pelos múltiplos processos. Se um deles
tiver problemas, apenas o cliente conectado a ele
será desconectado. Todo o restante do banco de
dados continua funcionando normalmente.

O outro grande benefício é a escalabilidade.

Acredito que esta característica seja a responsável
por boa parte das instalações do ClassicServer. 2: Diagrama Classic Server
Mesmo em casos onde o cache dedicado produz
resultados inferiores ao cache compartilhado do SuperServer, a escalabilidade do ClassicServer
compensa. Basta adicionar mais hardware e pronto, seu servidor fica mais rápido. Mas esta
escalabilidade não vem de graça. Imagine que você tem 200 clientes simultâneos. São 201
processos, um para cada cliente e mais um para ficar ouvindo novas conexões. Seu sistema
operacional deve gerenciar todos estes processos e mantê-los em sincronia. Eles consomem muitos
recursos de kernel e isto significa que ele pode ser relativamente lento.

SuperClassic

A partir do Firebird 2.5, a equipe de desenvolvimento

decidiu usar o Firebird ClassicServer como base para
construir o Firebird 3.0, que será totalmente compatível
com SMP. O SuperClassic é o primeiro passo nessa
direção. É uma evolução do ClassicServer que resolve o
maior problema que o Classic Server tem: Todos aqueles
processos o deixam lento e tornam a manutenção mais
difícil.

Bem-vindo ao SuperClassic: Um único processo com

cache dedicado. Olhando assim e levando em
consideração o nome, parece um híbrido entre o
ClassicServer e o SuperServer, mas não é. O que fizeram
foi encapsular todos aqueles processos em threads. Agora cada cliente tem um thread dedicado
dentro de um único processo.

Criar centenas de threads é muito mais barato que criar centenas de processos e não existe perda de
escalabilidade. A sincronização entre os caches pode ser feita diretamente em memória, o que reduz
o custo de I/O. E outros controles que antes eram inter-processo agora são inter-thread, muito mais
rápidos.
 Conclusão

Esta compilação dos casos mais comuns de uso é uma sugestão e serve apenas como guia, um
ponto inicial na sua escolha. A sua instalação pode ter detalhes próprios que não foram abordados
aqui.

 SuperServer
1. Bases de dados pequenas ou pouco acessadas
2. Servidores pequenos
3. Ambientes onde o cache compartilhado é mais vantajoso que a escalabilidade do SuperClassic
 ClassicServer
1. Ambientes onde a estabilidade é a maior preocupação
2. Servidores multi-processados
3. Grandes bases de dados com centenas de usuários
 SuperClassic
1. Servidores multi-processados
2. Grandes bases de dados com centenas de usuários
3. Ambientes onde o cache dedicado é mais vantajoso que o cache compartilhado do SuperServer
4. Ambientes onde o ClassicServer já não consegue escalar

Para efetuar as configurações necessárias para a utilização do Classic Server e SuperClassic com
melhor performance, será necessário aplicar os parâmetros abaixo de acordo com cada ambiente.

Quando instalado em um servidor dedicado, com um bom processador e memória, é possível fazer
algumas configurações no Firebird para melhorar o seu desempenho.O arquivo se localiza na pasta
(por padrão) C:/Program Files/Firebird/2.5/firebird.conf, dentro dele há várias configurações dos
parâmetros com suas explicações, porém as linhas destes parâmetros estão com o simbolo de # no
inicio das linhas , para deixar as mesmas comentadas e o Firebird utilizar as configurações
padrões.Para a correta configuração, deve-se colocar estas linhas abaixo de acordo com cada
ambiente , sem o simbolo de #.

Configurações

 [SuperServer] Configuração para  [SuperServer] Configuração para

servidor com processador dual-core, e servidor com processador quad-core, e
pelo menos 4GB memória: acima de 8GB memória:
DefaultDbCachePages = 4096 DefaultDbCachePages = 16384
FileSystemCacheThreshold = 67108864 FileSystemCacheThreshold = 268435456
FileSystemCacheSize = 70 FileSystemCacheSize = 80
CpuAffinityMask = 3 CpuAffinityMask = 3

 [SuperServer] Configuração para  [SuperClassic] Utilização em ambientes

servidor com processador dual-core, e com muitos usuários e processos,
pelo menos 8GB memória: configuração para servidor com
DefaultDbCachePages = 8192 processador dual-core, e pelo menos
FileSystemCacheThreshold = 134217728 8GB memória:
FileSystemCacheSize = 70 DefaultDbCachePages = 384
CpuAffinityMask = 3 TempBlockSize = 2048576
TempCacheLimit = 567108864
LockMemSize = 5048576
LockHashSlots = 30011

OBS: Importante sempre fazer um backup do arquivo Firebird.conf antes de realizar este
procedimento, pois a configuração incorreta do mesmo pode causar o não funcionamento de suas
aplicações.