Orientações e Configurações de Servidores

De Tek-System Wiki
Ir para navegação Ir para pesquisar

O objetivo desse documento é apresentar elementos que contribuam para o esclarecimento de dúvidas, não tem por finalidade a resolução de problema ou receita. Afinal, a resolução difere para cada situação e seu contexto, exigindo análise, deliberação e monitoramento constante.

A incumbência desse trabalhado não se aplica a Tek-System, nem mesmo compõem a carteira de serviços oferecidos pela empresa. Para esse tipo de trabalho necessário empresa qualificada na área e grande experiência de mercado, por isso sugerimos a IBSurgeon


Sistema Operacional

Windows

- Algumas versões do Windows Server (ex: 2016) usam o gerenciamento de energia “Equilibrado” por padrão. Trocar para “Alta Performance” = ganho de 20% em média, operações que exigem CPU podem se beneficiar ainda mais; 

 Equilibrado.....: TPC-C (operações) 17.029 | Restore (gbak) 4h07
 Alta Performance: TPC-C (operações) 21.226 | Restore (gbak) 2h35

(Fonte: https://www.firebase.com.br/artigo.php?id=3098)

- Reinicie o servidor mensalmente, evitando “desktop beap”, apesar de não ser uma situação muito comum, mas ocorre o sistema operacional esgota seu limite de criação de novos processos. 

 "Not enough storage is available to process this command"

 "Espaço insuficiente de armazenamento para processar este comando"

Erro do SO causado por excesso de chamadas de sistema ocorre com qualquer sistema não só com o nosso. Deve identificar qual programa que está sendo chamado excessivamente e desativa-lo;


- Mantenha a atualização automática desativada, a execute periodicamente de forma manual em momentos mais propícios (fora do horário de expediente). Durante o processo de atualização é consumido grande quantidade de recursos, impactando drasticamente no sistema, além da possibilidade de reiniciar automaticamente após a instalação (Processos: TrustedInstaller.exe e WuauServ).

Linux

- Se Linux Ext4 não utilizar a opção nobarrier, a versão 2.5 do FB está com problema de compatibilidade.

- Barrier ligado + FW ligada = “performance lastimável de escrita”. Um dos dois tem que ficar desligado para obter performance, considere desligar o barrier, desde que o armazenamento tenha BBU e a FW fique ligada.

- Se Linux e com frequência ocorre erro “wrong record length” verifique a RAM (Fonte: http://ib-aid.com/en/articles/how-to-quickly-check-ram-on-linux/)

- Verifique os limites para o processo do Firebird (SuperServer ou SuperClassic) com o seguinte comando: cat /proc/<firebird_proc_id>/limits E preste atenção na linha com o parâmetro de número máximo de arquivos abertos. O Firebird pode usar até 4 handles por conexão, e se você encontrar algo como: 

 Max open files   4096   4096 files

A linha acima significa que o número de conexões servidas pelo Firebird será limitado em torno de 1.000. Se você tem, por exemplo, 4 bancos de dados no servidor, as conexões de todos eles são considerados. 

 Aumente o valor para 65535.

Após reiniciar o Firebird, certifique-se de checar novamente para ver se as mudanças foram aplicadas. Para o Classic, é necessário checar e aumentar os limites para o usuário “firebird”. (Fonte: https://www.firebase.com.br/artigo.php?id=3098)

- Recomenda-se: Recomendadas do Linux são: CentOS 7.x e Ubuntu 16, 18; CentOS 6 menos performasse que o 7, assim como o Ubuntu 12 em relação ao 16 (Fonte: https://www.firebase.com.br/artigo.php?id=3098)

- Use o irqbalance, o uso do irqblalnce geralmente melhora a performance do Firebird e o balanceamento de uso de CPU em servidores com muitos cores.

- Versões que dependem do inetd/xinetd possuem limitação padrão de poucas conexões. Necessário alterar o arquivo de configuração, ex: 

 # firebird2.5-classic uses /etc/xinet.d/firebird2.5 by default 
 servicegds_db 
 { 
   flags           = REUSE NODELAY 
   socket_type     = stream
   wait            = no
   user            = firebird
   log_on_success += USERID
   log_on_failure += USERID
   instances       = UNLIMITED
   per_source      = UNLIMITED
   server          = /usr/sbin/fb_inet_server 
 }


Driver

- Tipo de HD recomendado em ordem decrescente:

1º) SSD (1000++ IOPS): fornece IO aleatório e paralelo muito melhor do que movimentações tradicionais. O IO aleatório é crítico para ler e escrever dados distribuídos através de um arquivo de banco de dados grande. É uma obrigação que você use discos corporativos (enterprise) com o aumento do número de ciclos de leitura/gravação, caso contrário, é altamente possível que você perca dados devido a falha. Utilize SSDs de marcas confiáveis e instale o driver do fabricante.
2º) SAS (175 > IOPS)
3º) SATA (70 e 140 IOPS)
Não utilizar drives do tipo flash, pois possuem uma estrutura que dificulta e muito a recuperação do BD quando há corrupção;

-Recomenda-se haver drives separados para tipos definido abaixo, esses elementos exigem muito recurso de I/O que acaba sendo concorrentes e comprometendo o desempenho:

- Sistema Operacional
- Banco de dados
- Arquivos temporários (S.O, BDD, aplicativo etc.)
- Backups: Armazene backups de banco de dados na unidade física dedicada (RAID). Ele irá separar IO de leitura e gravação durante o backup e aumentar a velocidade de backup e diminuir a carga para a unidade principal. É especialmente importante quando os backups são feitos enquanto os usuários estão trabalhando com o banco de dados.

- Ter um bom espaço em disco na unidade onde está instalado o Firebird e pastas temporárias do SO. O FB utiliza temporariamente alocação de arquivo em disco para diversas operações (ex: ordenação), assim, pouco espaço pode comprometer diretamente seu desempenho, ausência de espaço leva a inviabilidade de execução de query e corrupção da base de dados;

- Ter um bom espaço em disco na unidade onde está à base de dados, o FB necessidade de um bom espaço para efetuar as manipulações do BD.

- O tamanho do drive deve ser de 400% do tamanho do banco de dados atual ou superior, pensando apenas na projeção de crescimento, outros elementos devem ser considerados adicionalmente.

- Se SSD e não for corporativo (enterprise) após 2 anos de uso efetuar substituição, pois possuem limite de gravação.

- Utilizar controladoras de disco que possua cache embutido (fonte: http://www.firebase.com.br/fb/artigo.php?id=2718)

- Verifique o subsistema de disco: Verifique se há bloqueios ruins e outros problemas de hardware (incluindo superaquecimento) nas unidades. Problemas de hardware podem diminuir significativamente o desempenho de IO e levar a corrupções de banco de dados.

- Não usar drive externo SAN/NAS: já que a velocidade de um servidor de banco de dados Firebird depende da velocidade de acesso à 4k blocos individuais no dispositivo. Drives SAN / NAS externos são grandes para transferência de centenas de MB de dados de um local de arquivo para outro. No entanto, as transferências de servidores Firebird centenas de milhares de pequenas páginas entre memória e disco rígido físico encontrado em diferentes deslocamentos de arquivo.

- Saber o tamanho do cluster utilize no CMD chkdsk. Acesso o cmd com adminstrador e execute: chkdsk c:

RAID

Acesso ao disco é um fator limitante, e escrever em muita local força muitos deslocamentos e com uma alta carga de trabalho pode ser um problema.

- Sugestão: Para SSD - RAID 1, para HDD - RAID10, para backup HDD - RAID1. SAS, SATA, nSAS

- Se for utilizar usar o modelo RAID 10: é 15-25% mais rápido que RAID1 ou RAID5.

- Problemas comuns de IO:

- Nenhuma bateria no RAID: Verifique se ele tem bateria de backup (BBU) instalado e operacional - alguns fornecedores não fornecem BBU por padrão. Sem BBU, o controlador desativa a

cache, e RAID funciona muito lento, ainda mais lento do que as unidades SATA usuais.

- Drive inadequado ou genérico
- Escrita por meio das configurações de cachê: Com BBU instalado (e servidor com UPS), verifique se seu cache está configurado para write-back (não write-through). «Write-back» permite escrever cache do controlador.
- Cache de leitura desativado:
- Em ambientes virtuais (VMWare, Xen, Hyper-V) banda IO pode ser muito limitada um dos discos em RAID 1/5/10/etc pode ser corrompido.
- Configuração RAID incorreto


Memória

- Reserve pelo menos 40% da RAM para o cache do Windows, e 30% para o cache do Linux.

- RAM: 8 GB ou mais (ECC é OK, mas não obrigatório) Muitos fatores devem ser levados em consideração, mas basicamente podemos estimativa para o Firebird SuperServer: 

 (Número de páginas no cache * Tamanho da página) + Classificação do tamanho do cache

Exemplo para SuperServer (Firebird 2.5): 1 banco de dados, 100 usuários, o tamanho da página da base de dados é 8 KB, o número de páginas no cache da página é 10000, o tamanho da cache de classificação é 1024 MB: 

 10000 * 8 KB) + 1024 = 1102 MB

Exemplo para SuperServer (Firebird 3.0 e 4.0): 1 banco de dados, 100 usuários, o tamanho da página de banco de dados é 8 KB, o número de páginas no cache de página é 100000, o tamanho do cache de classificação é 1024 MB: 

 (100000 * 8 KB) + 1024 = 1805 MB

- Gerenciador de Tarefas do Windows mostra a memória usada para cache como memória livre! Utilize o RAMMAP* para ver o real consumo.

(Fonte: http://ib-aid.com/en/articles/firebird-hardware-guide/ | http://www.firebase.com.br/artigo.php?id=3098)


Interface de rede

- Comum o uso de VMs, deve-se atentar ao configurar o uso de interface de redes. Mais de uma VM utilizando a mesma interface acaba gerando gargalos e “escondendo” o problema; comum por exemplo colocar o BD em uma VM e o servidor de aplicação em outra e não ter um bom desempenho, devido ao gargalo da rede.

- Atenção ao uso de redes de alta carga

- "GAS Tecnologia Filter Drvier": A GAS Tecnologia é uma empresa que entre outras coisas fornece para diversos bancos do país um plugin chamado G-Buster que ajuda a proteger as transações bancárias efetuando varreduras no trafego de rede, essa varredura há um preço alto, o tráfego de rede ficará mais lento. Há versões que são incompatíveis com algumas atualizações do Windows, provocando consumo excessivo da CPU. Em alguns casos malwares se infectam nesse arquivo agravando o problema. A orientação é a não utilização desse tipo de software em servidores (Fonte: http://www.firebase.com.br/fb/artigo.php?id=2503)


Máquinas virtuais

- Cuidado com o Overcommit de Memória: As VMs podem ser configuradas de forma a ter mais memória do que existe fisicamente na máquina host, um recurso chamado de Memory Overcommit (o nome pode mudar dependendo do sistema de virtualização utilizado). Isso significa que nos picos de uso de memória (tanto na VM com o Firebird, como em qualquer outra rodando no mesmo host) poderá ocorrer swap, ocasionando uma grande degradação de performance. Para VMs em servidores de banco de dados de alta performance, a configuração de memória deve ser estática.

- Normalmente as VMs são criadas com limites padrões de CPU e I/O, que podem ser muito baixos, como 50 IOPS e 10% CPU. Verifique a configuração da máquina virtual e remova todos os limites – servidores de bancos de dados de alta performance devem utilizar toda a capacidade de CPU, bandwidth e I/O.

- Máquinas virtuais sempre oferecem menor desempenho que uma maquina real, sem o objetivo é melhor desempenho evite-a. Se for utilizar nunca utilizar a VM sobre um sistema operacional, mas no host da máquina.

Firebird

Instalação

- Recomendação em ordem decrescente:

1) Linux: possível obtenção de maior taxa de I/O a outros S.O.
2) Windows Server (Win2019)

- Qual arquitetura escolher para escalar melhor: 

 A partir do Firebird 3: SuperServer
 Classic como serviço no Windows pode limitar o número de conexões aceitas (250-300), e pode estoura a memória do heap

- Não instalar SuperClassic em SO 32 Bits (fonte: http://www.firebase.com.br/fb/artigo.php?id=2513)

- Não instalar Classic quando há pouca memória disponível ou for 32 bits (fonte: http://www.firebase.com.br/fb/artigo.php?id=2308)

- Não usar como servidores Windows XP e 7, tem limite de 10 conexões de rede simultâneas (fonte: http://mail.firebase.com.br/pipermail/lista_firebase.com.br/2012-August/078364.html)

- Use o SuperServer 3.0 no Firebird 3: Se você usar Classic ou SuperClassic em 2.5, considere a migração para o Firebird 3.0 SuperServer, agora ele pode usar vários núcleos e combiná-lo com as vantagens do cache compartilhado

- Quando servidor 64 bits utilizar Firebird 64 bits: O FB 32 bits tem limite para uso de memória de 3GB, ao alcançar o limite passa a recusar novas conexões;

- Não instalar em ambientes virtuais (VMWare, Xen, Hyper-V) banda IO é mais reduzida, perdem de 20% a 80% da sua velocidade.

- Não utilizar “NUNCA” S.O. de PDC (Primary Domain Controller) junto com BDD: PDC desativa o cache de gravação no HD correndo risco de perda de dados e corrupção. E a performance de gravação será sofrível. (fonte: http://www.firebase.com.br/fb/artigo.php?id=2716)

- Não use a autenticação SRP no Firebird 3 se você não precisar: conectar com autenticação SRP é mais lento do que a conexão regular.

- Se Firebird Classic no Windows, habilite o flag «Permitir que o serviço interaja com a área de trabalho». Sem essa configuração, o desktop heap é limitado pelo Windows, e o Firebird não poderá abrir mais que 250-300 conexões

- Ligar compressão de tráfego em redes com alta latência, ativado pelo WireCompression no firebird.conf (Fonte: https://www.firebase.com.br/artigo.php?id=3098)


Versões de DLL

- Em clients do SGDB deve ter as mesmas versões das dll’s: GDS32.dll e FBCliente.dll do servidor SGDB. Mas lembre-se que client não é o mesmo que estão, no sistema a ERP trabalha em sistema de multicamadas, assim o client é o servidor de aplicação.

Necessário observar na pasta dos executáveis de na System32 e SysWOW64 (no caso de 64 bits).

Para saber a versão do servidor FB 

 TekMonitor: Opção “Gerenciador de base de dados”, aba Informações
 IBExpert, menu: Serviceces / Server Properties/log, selecione o servidor e mande executar:

Observe a valor da propriedade “Server Version”, ex: “Server Version: WI-V2.5.1.26351 Firebird 2.5”.


Tuning (Customizações) Firebird.conf e databases.conf

  • ATENÇÃO *

Não há receita de bolo, cada ambiente a aplicação diverge sobre seu comportamento. O tuning é realizado sob analises e monitoramentos, chegando necessidade, conferindo comportamentos e a necessitando e o acompanhamento continuo.

Cuidado com ajuste de valores incorretos e/ou inválidos, causa performasse ruim, problemas e comparação e pode levar a corrução o BDD.

Um bom ponto de partida para a configuração do firebird.conf e databases.conf: https://cc.ib-aid.com/democalc.html

Abaixo são orientações para situações específicas, sem considerar as demais adversidades dos diversos cenário.


- Problema com memória/cache (quando Super-Server): Alterar a quantidade máxima de espaço temporário que pode ser armazenada na memória. 

 Aumente o valor do parâmetro #TempCacheLimit (especifica o tamanho do cache do espaço temporário para ordenação). Os valores padrão são muito baixos (8Mb para Classic e 64Mb para SuperServer), use 64Mb e 128mb para Classic e 364mb a 1Gb para SuperServer e SuperClassic. Se for pequeno o cache limite acaba ordenando em disco e não na memória;

 Passar o #DefaultDbCachePages (cache dos buffers de página)
   FB 2.5 SuperServer de "2048" para 10000,
   FB 3.0 SuperServer para 50000 páginas
   Isso define o número de páginas a partir de qualquer banco de dados que pode ser realizada no cachê ao mesmo tempo (com isso 16k (tamanho da página) x 9999 ~= 160Mb). Se aumentar muito faz um duplo cachê, pois o SO também faz cachê, passe # FileSystemCacheThreshold se “0” para desligar o cachê do sistema de arquivos do SO; Se o #FileSystemCacheThreshold for menor que o #DefaultDBCachePages ou que o page buffers, o cache de arquivos do sistema operacional não será usado, levando a problemas de performance. Em 99% das vezes, é melhor que o cache de arquivos seja usado. Para ter certeza que isso acontecerá, use a seguinte regra para configurar os parâmetros: #DefaultDBCachePages = X  #FileSystemCacheThreshold = X+ N, N>1;

Não deixe de ler https://www.firebase.com.br/artigo.php?id=3098 

 Passar o #FileSystemCacheSize para 50: Esta configuração controla a quantidade máxima de memória RAM usada pelo cache do sistema de arquivos do Windows.

- Problema com gestão de espaço temporário: 

 O armazenamento temporário é usado pelo módulo de separação, que também é destinado a armazenar os conjuntos de dados temporários etc.

 Aumentar #TempBlockSize: 
   FB 2.5 de "1048576 " para "2048576"
   FB 3.0 de 1M para 2M

(Fonte: http://www.firebase.com.br/fb/artigo.php?id=2680)

- Problema com Manager Look: queda de desempenho no meio do dia, quando a fila esta grande: 

 Aumentar o #LockMemSize: que são bytes de memória compartilhada alocada para o gerenciador de bloqueio
  FB 2.5 de "1048576" para "10485760"
  FB 3.0 de 1M para 9M

(Fonte: http://www.firebase.com.br/fb/artigo.php?id=222#Lock_Mem_Size | https://www.firebase.com.br/artigo.php?id=3098) 

 Aumentar o #LockHashSlots:
   FB 2.5 de "1009" para "10091" (Fonte: http://www.firebase.com.br/fb/artigo.php?id=222#Lock_Hash_Slots) 
   FB 3.0 de “8191” para “30011” (Deve ser um número primo)

- Problema com Garbase Collection: 

 Deve identificar: onde? Quando? E quem?
 Teste rápido para saber se há problemas: verificar se o "Oldest snapshot" - "Oldest Transaction" é superior que o "Sweep interval" (padrão 20000)
 Quem: usar IBMonitoramento ou FBScaner

- Problemas com HD lento ou pouco espaço da instalação: 

 Se há outra unidade de disco com taxa de gravação/leitura superior à da instalação atual do Firebird e/ou possua mais espaço disponível superior pode ser direcionado para ele utilização da pasta temporário #TempDirectories = “d:\temp”. Na pasta temporária é, por exemplo, armazenado o cachê para ordenação dos resultados da SQL (order by).

- Problemas com espaço definir #TempDirectory: 

 Defina uso em unidade SSD ou RAM rápida para espaço temporário do SGDB: Diminuirá o tempo de grandes ordenações, restaurações, etc.
 Utilize driver rápido


Propriedades da Base de Dados

SQL Dialect

3

ODS Version

ODS (On-Disk Structure) é um número de formato de arquivo de banco de dados para a versão específica do Firebird 

11.2 FB 2.5
12   FB 3
13   FB 4

Sweep Interval

O intervalo de varredura padrão para um novo banco de dados é 20.000. O intervalo de varredura é a diferença entre a transação instantânea mais antiga ou OST (Oldest snapshot) e a transação interessante mais antiga ou OIT (Oldest Transaction). Isso não significa que a cada 20.000 transações ocorrerá uma varredura. Ocorrerá quando a diferença entre o OST e o OIT for maior que o intervalo de varredura. se houve necessidade de ampliar não passar de 60000, e nunca desative pois será necessário realizar manualmente. A não realização do sweep levando a amplitude da necessidade execução implica na degradação exponencial de performance.

Read Only

Desmarcado, diferente disso é utilizando apenas em sistemas embarcados

Forced Write

O Firebird é instalado com gravações forçadas (gravações síncronas) habilitadas por padrão. Os dados alterados e novos são gravados no disco imediatamente após a postagem. É possível configurar um banco de dados para usar gravações de dados assíncronas, por meio das quais os dados modificados ou novos são mantidos no cache de memória para liberação periódica no disco pelo subsistema de E/S do sistema operacional. O termo comum para esta configuração é cancelamentos forçados (ou desabilitados ). Às vezes, é utilizado para melhorar o desempenho durante grandes operações em lote.

  • AVISO: não desative as gravações forçadas: interrupções de energia, finalização forçada do serviço, se travar, o sistema de E/S ficará fora de alcance implica em perda de dados, e possivelmente em uma corrupção das integridades relacionais
Obrigatório: True

Page Size

Por padrão, os bancos de dados Firebird têm os seguintes tamanhos de página: 

 2,5 - 4096 bytes
 3,0 - 8192 bytes
 4.0 - 16384 bytes

O tamanho máximo da página é 16K até o FB 3, no FB 4 é 32K.

Analisando apenas a questão do drive, o ideal é trabalhar com o mesmo tamanho de cluster do disco da base, para ter uma referencia de 1 para 1 (Saber o tamanho do cluster utilize no CMD chkdsk. Acesso o cmd com adminstrador e execute: chkdsk c:)

No entanto o tamanho do page size ideal varia conforme tipo de hardware, sistema operacional, perfil, tipo e volume de dados armazenados.

Por exemplo, para bancos de dados com mais de 100 Gb em 95% dos casos, é melhor ter o maior tamanho de página disponível, para: 

- Diminua a profundidade dos índices. Recomenda-se ter índices com profundidade menor ou igual a 3. Índices com profundidade 4 e 5 serão muito mais lentos

- Aumente a utilização da RAM. O cache do Firebird é especificado em páginas, 1000 páginas com tamanho de página de 8K serão 8Mb de memória real e com 16K – 16Mb.

- Diminuir o número de páginas do sistema. Ele irá agilizar o acesso aos registros das tabelas grandes (menos saltos ponteiro-ponteiro-página de dados), e ajuda na preparação das grandes consultas SQL. Para aumentar o tamanho da página do banco de dados, o banco de dados deve ser copiado com a ferramenta gbak e, em seguida, restaurado com o parâmetro –page ( gbak –c –page 16384 ).

Observação: se você tiver um banco de dados com muitos blobs pequenos, aumentar o tamanho da página pode diminuir a fragmentação ou aumentar a fragmentação, e é difícil prever se isso aumentará ou diminuirá o desempenho.

Fonte: https://ib-aid.com/en/articles/23-more-ways-to-speed-up-firebird

Atenção: Qualquer mudança no tamanho das páginas implica diretamente nas configurações de cache do firebird.config, necessitando serem revistas.

Backup

- Use switch para gbak: aumenta a velocidade em até 20% do backup/restaurar, por exemplo: 

 Gbak -b -g -se service_mgr c:\db\ data.fdb e:\backup\data.fbk

- Com gbak evit -v, melhora o desempenho

- Backup/restore em um único passo: 

 gbak -b c:\BD.fdb stdout | gbak -c stdin c:\BD2.fdb

- As operações de gravação são executadas sequencialmente durante o processo de backup, o que significa que discos rígidos regulares de baixo custo com a interface SATA (HDD SATA) serão bons para backup uma vez que sequencialmente escreverão muito rápido.

- Use a unidade rápida para espaço temporário do SGDB: Isso diminuirá o tempo de grandes ordenações, quando o banco de dados estiver sendo restaurado, etc..

- Para backups quentes em meio a trabalhos recomenda-se a utilização do N-Backup

- Atente-se a disponibilidade de espaço sobe o numero de copias permanentes e a projeção de crescimento, e monitore.

- Periodicamente realize testes das copias, sob a possiblidade de voltar a produção, tempo e consistência

- Evite armazenar copias na maquina ou em dispositivos conectados ao servidor, são suscetíveis a danificar com o servidor, roubados ou sequestrados.


Manutenção

- Apague os arquivos temporários antigos do Firebird: O Firebird cria vários arquivos temporários para diversas operações: ordenação, processamento de BLOBs, tracing, etc. Esses arquivos são armazenados nos seguintes locais:

no Windows: C:\ProgramData\firebird
no Linux: /tmp/firebird

Normalmente, esses arquivos são removidos automaticamente, no entanto, algumas vezes isso não acontece (por exemplo, se o servidor for reiniciado brutamente). Verifique esses diretórios periodicamente e apague os arquivos antigos – pode haver vários gigabytes e apagá-los irá liberar espaço no drive do sistema.

- Reinicie o servidor periodicamente.


Avançado

- Acelere o banco de dados de segurança: Aumente o buffers do security”n”.fdb (o valor empírico máximo é 256); Mova o security”n”.fdb para o drive mais rápido do sistema (a operação é trivial no Firebird 3, mas no Firebird 2.5 exigirá uma reinstalação do Firebird no disco especificado) (Fonte: https://www.firebase.com.br/artigo.php?id=3098)

- Diminuir a profundidade dos índices depth, deve ser <=3. Depth >= 4 terão uma performance muito ruim. Uma forma de realizar é aumentar o tamanho das páginas.

- Diminuir o número de páginas na base: Aumentará a performance de acesso a registros de tabelas enormes (menos “pulos” entre páginas de ponteiros e de dados), e ajuda na preparação de comandos SQLs extensos.

- Aumentar o consumo de RAM: O cache do Firebird é configurado em número de páginas, 1.000 páginas de cache, em uma base com páginas de 8K, significa o uso de 8MB de memória, e 16MB com páginas de 16K.

- LINGER: Permite manter o cache “quente”, mesmo após a desconexão do último usuário. Exemplo para manterá o cache por 60 segundos após o término da última conexão: 

 ALTER DATABASE SET LINGER TO 60

gfix -nolinger (fecha imediatamente a base após o último attachment ser encerrado)


-Não use o recurso “no_reserve”. O flag “no_reserve”, quando ativo, faz com que o Firebird deixe de reservar 30% de espaço nas páginas de dados para armazenar versões temporárias de registros, que são criadas após um update ou um delete. Esse flag permite que os dados sejam armazenados de forma mais compacta (diminuindo o tamanho do arquivo da base de dados), mas no caso de um UPDATE/DELETE, todas as mudanças ocorrerão em uma nova página de dados, fazendo com que essas operações se tornem mais lentas. Sendo assim, só ligue esse flag se sua base de dados for ReadOnly (somente leitura). Verifique se o flag está ativo usando o gstat –h base_de_dados e verificando a linha “Attributes”. Desligue o flag com o comando: gfix -use reserve database Depois desse comando, novas páginas de dados serão criadas com espaço reservado. No entanto, para se beneficiar completamente da mudança, é necessário fazer um backup/restore da base de dados com o gbak, para que todas as páginas sejam criadas com reserva de espaço. Obviamente, o tamanho da base de dados irá aumentar após remover o flag no_reserve e fazer o backup/restore.


SQL lentas em uma base de dados em específico

- Verificar sem todos os INDEX estão ativos ou a inexistência de algum;

- Execute a procedure RECALCULA_INDEX: Recalcule estatísticas de índices regularmente. Atualizar estatísticas de índices para as tabelas com mudanças frequentes ou maciças com o comando SET STATISTICS, permite que o otimizador Firebird escolha melhores planos SQL. O TekAgendador disponibiliza agendamento para isso.

- Verificar se há atraso de transações: necessidade de GC e Sweep, (transações antiga e não comitadas, ...), pode haver algum sistema não liberando transações, GC acima de 100000 já começa a ser notório acima de 400000 de difícil trabalho.

- Verificar se a base de dados está corrompido com Validation (Validate Database e Validate Full), necessário uso exclusivo da base.

- Efetuar Backup/Restaure (corrige certos erros, retorna o contador de multformat, reorganiza as páginas no disco etc..).


Principais motivos para corrupções

- Queda de energia, desligamento bruto

- Oscilação/intermitência da rede;

- Uso de dll’s (fbclient.dll e gds32.dll) com versões diferentes do Firebird do servidor (dlls na pasta do executável, System32 ou SysWOW64); (fonte: http://www.firebase.com.br/fb/artigo.php?id=2284)

- Falta de espaço na unidade onde está local do BD (deve haver pelo menos um 1GB disponível na unidade onde está a base)

- Falta de espaço na unidade de arquivos temporário do Firebird (por padrão é na mesma unidade da instalação do Firebird a não ser que seja alterado no .conf)

- Propriedades indevidas do BD (force write, entre outras, veja acima com usar as propriedades do BD) e/ou configurações indevidas do Firebird (Fonte: http://www.sinatica.com/blog/en/index.php/2008/08/forced-writes-firebird-database-corruption)

- Hardware com problema, em especial HD (problema em algum setor), mas também controladora, cabeamento da rede, instalações elétricas, etc..

- Problemas na memória RAM;

- Uso indevido de Raid (veja acima informações sobre uso da raid)

- Uso de S.O. pouco seguro (ex: Win 9x, ME e XP).

(Fonte: http://www.firebase.com.br/fb/artigo.php?id=48) (Fonte: https://ib-aid.com/articles/firebird-and-interbase-corruptions-reasons/)


Antivírus

- Certifique-se que se o servidor tiver um antivírus instalado, que ele não esteja “rastreando” as bases de dados, os arquivos temporários criados pelo Firebird (c:\ProgramData\Firebird) e o próprio sistema.

- Não recomendamos o uso do Kaspersky Server em conjunto no servidor, consome muito recurso de rede de processador. Faz uso do SGDB (Sistema de gerenciamento de banco de dados) SQL Server consome grande quantidade de recursos, por haver grande volume de acesso a disco mesmo prioridade concorrerá diretamente com o sistema para consumo dos recursos

- Colocar a pasta da Tek-System nas exceções

- Configurar de modo que não faça varredura durante o expediente


Midas

- Versão atual: 24.0.xxx.xxx

- Registrar ou não?: Orientamos não efetuar o registro, é comum efetuar o registro da midas na pasta system por exemplo, ocorre que em uma mudança de versão ela não é atualizada e o sistema a consome ao invés da que está sem sua própria pasta; Outros sistema também podem fazer o uso da midas e efetuar seu registros em outro diretório e o sistema passar a consumi-la.

- Registrar:

Ao abrir o CMD execute como administrador, do contrário mesmo apresentando mensagem de registro realizado com sucesso pode não ter sido realizado;
Deve-se observar se o sistema operacional é 32 ou 64 bits, se for 32 deve utilizar regsvr32 da system32, se for 64 bits deve usar o da SysWOW64:
 Exemplo:
   p/ Windows 32 Bits: C:\Windows\system\regsvr32 C:\Tek-System\Exec \midas.dll
   p/ Windows 64 Bits: C:\Windows\SysWOW64\regsvr32 C:\Tek-System\Exec \midas.dll

- Desregistrar

Mesmo processo anterior, mas adicionar parâmetro “-u” na linha de comando.


Análise e monitoramento

- Para checar problemas de IO:

Windows:
 HDTune: Sistemas\Utilitários\Analise de Servidores\HDTune
 CrystalDiskMark: Sistemas\Utilitários\Analise de Servidores\CrystalDiskMark
Linux:
 HDParm:
 IOMeter:

- Para checar quem está causando GC no BD 

 TekMonitor
 IBMonitoramento (Pago)
 FBScaner (Pago) 
 IBExpert (Pago)
 BI (Tek-System) - Indicadores

- Identificar Querys ruins 

 TekMonitor
 IBExpert (Pago)
 FBScanner (Pago)
 Sinática: (Pago) [descontinuado]


TekAgendador

Agendamentos de manutenção da base de dados:

- Opção de validade do Firebird, deve-se utilizar opção compatíveis conforme Firebird, interesse utilizar para forçar o Sweep por exemplo

- Recalculo de Index: força o recalculo das estatísticas de índices da base de dados

- Desconectar base de dados: Interessante utilizar para desconectar conexões a mais de X minutos conectados, coloque longo tempo exemplo 480 min (8 hrs x 60 min)


TekMonitor

Configuração de monitoramento:

São 97 elementos divididos em quatro grupos: Servidor, SGDB, BDD e Serviço

Conforme o modo selecionado mudará o tempo de periodicidade e alguns parâmetros de análise

Periodicidade: Tempo em minutos para execução, utilizar Zero para inativar
Satisfação: Forma de análise do elemento
Valores: Mínimo e Máximo, sendo informação, alerta e crítico; Sendo que informação apenas registra nas notificações, diferente de Alerta e Critico que também pode conforme configuração disparar e-mail.

Incidência de notificação: Quando que irá registar e poderá enviar o e-mail:

Nunca
Diária Posteriormente: Registrará, mas enviará o e-mail apeno ao final do dia
Diária na Primeira Incidência: Registrará, e enviará o e-mail apenas na primeira incidência do dia
Sempre: Registrará e enviará o e-mail em toda incidência
Única vez: Registrará e enviará o e-mail apenas uma vez

- Notificações

Elementos informativos, avisos e críticos apurados no monitoramento


- Monitoramento do Servidor

Percentual de uso da memória em uso e Swap
Latencia da rede
Percentual de uso do processador
Carga da bateria (depende da disponibilidade de drive e hardware com repasse essa informação)

- Monitoramento da base de dados

Atividade de I/O: Estes gráficos e lista mostram informações breves sobre as principais declarações que executam muitas leituras. Isso significa que elas consomem IO significativas e podem afetar o desempenho de outras consultas. As instruções SQL com valores de pico devem ser cuidadosamente verificadas para o desempenho ideal.
Atividade de transações: AOT, AIT, OST, Next
Leitura de registros: "Leituras sequenciais / leituras indexadas" nos mostra a relação total entre leituras seqüenciais (não indexadas) e leituras indexadas no aplicativo.
Operações em registros: Visão geral das operações de escrita: relação entre INSERTs / UPDATEs / DELETEs entre todas as conexões do banco de dados. Na tabela dos melhores escritores, você pode ver as conexões com o maior número de operações de gravação. É útil identificar aplicativos ou módulos de software que executem um número excessivo de atualizações ou exclusões (que são as operações mais perigosas em termos de coleções de lixo).
Transações pendentes: Este gráfico mostra a quantidade de pendentes ao longo da linha de tempo. Existem dois tipos de transações pendentes, aquelas que estão aguardando o garbage collector e as que estão aguardando o sweep.
Memória em uso: O gráfico de "uso da memória" mostra a memória total usada por todas as conexões ativas e o pico da memória alocada para eles no passado. A lista dos principais anexos por uso de memória nos mostra os maiores consumidores de memória entre seus anexos. É útil encontrar aplicações ou módulos de software com uso excessivo de memória.
Espaço em disco: Disponível apenas se o SGDB estiver na mesma máquina do TekMonitor
Objetos: Este gráfico mostra o total de objetos na base de dados ao longo da linha de tempo: Conexões, Transações e Comandos
Arquivo: Tamanho da base de dados
Mutex Wait: Porcentagem de tentativas de adquirir a tabela de bloqueio bloqueada. [I.e. ((Adquirir blocos) / (adquire)) * 100]
Disponível em “https://teksystem.com.br/tekwiki/index.php?title=Orientações_e_Configurações_de_Servidores&oldid=3386”