Ajustando um banco de dados Firebird SQL de 1,7 Terabyte
Alexey Kovyazin, 14 de julho de 2014
Como você lembra dos nossos artigos anteriores, investigamos mitos sobre a degradação de desempenho do Firebird ( /br/articles/firebird-performance-degradation-tests-myths-and-truth/), onde criamos vários bancos de dados de 9Gb a 30Gb, e também testamos um banco de dados Firebird muito grande (1,7 terabyte) (/br/articles/more-details-about-1-7-terabyte-firebird-sql-database/).
Todos os testes foram realizados no mesmo hardware, que é uma configuração de baixo orçamento: CPU AMD-FX8350, RAM 16GB, RAID1 de software SATA 2x4Tb com discos HDD Seagate, sistema operacional Windows Server 2008R2 (2008R2 é 64 bits), e com a mesma configuração do Firebird: Firebird 2.5.2 64-bit, SuperServer, com buffers de página e TempCacheSize aumentados. Você pode baixar este arquivo de configuração SuperServer gratuitamente neste local: /br/optimized-firebird-configuration/
Como resultado, tivemos o seguinte quadro de desempenho do banco de dados:
Figura 1. Degradação de desempenho de 9Gb a 30Gb, e 1,7Tb
O ponto #11 é a marca de desempenho para o banco de dados de 30Gb e o #12 para o banco de dados de 1,7 Terabyte - o tamanho do banco de dados cresceu 60 vezes (de 30Gb para 1813Gb), a perda de desempenho foi de 2,4 vezes (de 407 para 169 pontos).
Então, a pergunta é: podemos melhorar o desempenho do Firebird no mesmo hardware com ajustes de configuração?
E a resposta é: sim!
Turbinando o FirebirdSQL
Como você lembra, neste teste executamos 20 conexões simultâneas que realizam INSERTs intensivos e, menos intensivos, UPDATEs.
Todos os SELECTs são curtos e bem definidos, com planos de execução SQL eficientes, então esta é uma aplicação OLTP (processamento de transações online) típica. Para tais aplicações, o mais crítico para o desempenho é o processamento paralelo. O Firebird SuperServer 2.5.2 não é adequado para processamento multi-thread - ele usa efetivamente apenas 1 núcleo por banco de dados, e este fato torna o SuperServer não uma boa escolha para aplicações OLTP.
Então, precisamos mudar a arquitetura do Firebird para Classic ou SuperClassic, que suportam processamento multi-thread e utilizam múltiplos núcleos da CPU (há 8 núcleos na CPU AMD-FX8350).
Em seguida, alguns ajustes são necessários, já que a configuração padrão do Firebird não é ideal para o nosso sistema de teste.
Parâmetros de ajuste no firebird.conf
Cache de páginas
Então, para melhorar o desempenho OLTP, decidimos testar as arquiteturas Classic e SuperClassic. Um dos parâmetros-chave para Classic e SuperClassic é o número de buffers de página no cache. Ao contrário do SuperServer, Classic e SuperClassic alocam cache de páginas por conexão.
Para mais detalhes sobre as arquiteturas do Firebird na versão 2.5, você pode revisar esta tabela: http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf
Há uma fórmula fácil para calcular o uso de memória do cache de páginas para diferentes arquiteturas do Firebird:
-
- SuperServer - cache de páginas único por banco de dados. O tamanho padrão do cache de páginas é 2048 páginas, a recomendação mútua é 10000 buffers. No nosso caso, o cache era 16k (tamanho da página) x 10000 ~= 160Mb. Isso é para todas as conexões.
-
- Classic e SuperClassic - o mecanismo aloca cache de páginas para cada conexão. O tamanho padrão é 75 páginas, então 16Kb (tamanho da página) x 75 = ~= 1,17 Mb, para cada conexão.
Obviamente, o tamanho do cache de páginas deve ser aumentado, já que 75 páginas por conexão é muito baixo. Mostraremos abaixo os resultados de vários valores diferentes para o tamanho do cache de páginas.
LockHashSlots
Internamente, o mecanismo do Firebird usa uma tabela de locks para solicitar e adquirir locks para objetos internos dentro do banco de dados, e para Classic e SuperClassic há o parâmetro LockHashSlots (valor padrão é 1009). Ele deve ser aumentado sob alta carga, para diminuir as cadeias de hash na tabela de locks. Bem, “alta carga” parece ser qualquer aplicação multiusuário do mundo real, então o definimos como 30011 (para todos os testes).
LockMemSize
O parâmetro LockMemSize é usado para definir o tamanho inicial da tabela de locks (valor padrão é 1048576). O mecanismo pode aumentar o tamanho da tabela sob demanda. No entanto, o aumento da tabela de locks é caro em termos de CPU e outros recursos, pois é realizado através de remapeamento de memória. Então o definimos como 7Mb, para economizar algum tempo e recursos de CPU.
Execuções de teste
Fizemos várias execuções de teste com vários valores de cache de páginas, com os seguintes resultados:
| Buffers de página | Classic, pontos de teste | SuperClassic, pontos de teste |
|---|---|---|
| 256 | 299 | 372 |
| 512 | 371 | 359 |
| 768 | 362 | 386 |
| 1024 | 312 | 387 |
| 1500 | 390 | 392 |
| 2048 | 285 | 284 |
Tabela 1. Execuções de teste para Classic e SuperClassic
Como você pode ver, Classic e SuperClassic são muito mais eficazes que o Firebird SuperServer para esta tarefa: os resultados dos testes melhoraram de 169 pontos para 300-400, isso está próximo dos resultados que tivemos para o banco de dados de 30Gb!
É melhor ver os resultados no seguinte gráfico:
Figura 2. Resultados dos testes para banco de dados de 1,7 Terabyte
Você pode ver que o melhor desempenho (tanto em Classic quanto em SuperClassic) foi com 1500 páginas por conexão, então o tamanho do cache de páginas por conexão foi:
1500x16k ~= 23,4Mb
Com 2000 páginas por conexão, o desempenho diminuiu significativamente. Parece que em algum lugar entre 1500-2000 páginas, a vantagem do cache tornou-se menor que a sobrecarga causada pelas interações da tabela de locks entre processos para sincronizar páginas nos caches de cada processo de servidor. Obviamente, para um número maior de conexões, isso acontecerá mais cedo, por isso os servidores Classic/SuperClassic são geralmente configurados com números como 256-512 páginas.
Há também uma queda no desempenho do Classic em torno de 768-1000 caches de páginas - não temos certeza de por que isso aconteceu.
Resumo
Nossos experimentos confirmam que o desempenho do Firebird pode ser aumentado com a seleção correta da arquitetura do Firebird (SuperServer, Classic ou SuperClassic) e com um ajuste apropriado de vários parâmetros importantes para a arquitetura específica.
Como resultado, um enorme banco de dados Firebird SQL de 1,7 Tb pode funcionar em hardware de baixo custo com desempenho suficientemente bom. Como resultado prático desses testes, criamos vários arquivos de configuração para todas as versões do Firebird e para todas as arquiteturas. Claro, eles não são ajustados para a aplicação e/ou hardware específicos, mas são melhores que os arquivos de configuração padrão, que são feitos para cargas muito modestas.
Conjunto completo de arquivos de configuração otimizados do Firebird: /br/optimized-firebird-configuration/
Sinta-se à vontade para fazer qualquer pergunta: [email protected]
O que vem a seguir?
Estamos trabalhando em um teste abrangente que comparará o desempenho do Firebird 2.5 e do Firebird 3.0, com simulação de carga do mundo real e um grande número de conexões. Fique ligado!