Degradação de desempenho do Firebird: testes, mitos e verdade
Alexey Kovyazin, 16 de maio de 2014
Você pode baixar este artigo em formato PDF.
Recentemente, na IBSurgeon, realizamos uma série de testes de desempenho com o Firebird 2.5.2. O Firebird 2.5.2 é a versão mais popular do banco de dados Firebird, e seus usuários frequentemente têm dúvidas relacionadas ao desempenho do Firebird.
Uma das preocupações mais importantes em relação ao desempenho do banco de dados é a sua degradação. Muitos usuários afirmam que seus aplicativos de banco de dados apresentam problemas de desempenho ao atingir algum valor limite: pode ser 3Gb, 5Gb, o tamanho da RAM, 20Gb, etc. A afirmação mais comum é “o tamanho do banco de dados é maior que o tamanho da RAM”: quando o tamanho do banco de dados Firebird atinge o tamanho da RAM, relata-se que ele fica muito lento… Isso é verdade?
Decidimos realizar uma série de testes para verificar se existe essa degradação de desempenho relacionada ao crescimento do banco de dados. Decidimos simular o crescimento ao longo do tempo do banco de dados com a mesma carga no mesmo hardware, e para isso executamos 11 testes com bancos de dados de tamanhos entre 9Gb e 30Gb:
Figura 1. Tamanhos dos bancos de dados para os testes
Hardware de teste e configuração do Firebird
O hardware de teste tinha as seguintes características principais:
CPU AMD-FX8350, RAM 16GB, RAID1 de software SATA 2x4Tb drives Seagate, Sistema Operacional Windows Server 2008R2 (2008R2 é 64 bits).
Como você pode ver, é uma configuração de hardware de baixo custo; pode ser comprada por menos de USD 1000 no momento (maio de 2014), e pode ser considerada uma configuração típica de baixo nível - talvez, exceto pelos grandes drives SATA, mas de acordo com o relatório do fabricante, a velocidade dos drives SATA de 1Tb e 4Tb é quase a mesma.
Como o objetivo do teste era medir as mudanças de desempenho do sistema típico, usamos Firebird (64 bits) com arquitetura SuperServer, não Classic, para simular completamente a situação em uma pequena empresa - eles usam o que foi instalado originalmente por anos. Como você sabe, o SuperServer usa apenas 1 núcleo de CPU, então provavelmente Classic ou SuperClassic (que podem usar todos os núcleos da CPU) poderiam mostrar melhores resultados em termos de desempenho, mas nosso objetivo não era o ajuste de desempenho.
No entanto, ajustamos o firebird.conf com as mudanças óbvias que recomendamos para todas as instalações do Firebird SuperServer: aumentamos os buffers de página para 10000 e o espaço temporário para ordenação.
Todos os bancos de dados de teste foram criados com tamanho de página 16384, apenas para consistência.
Testes
Carga
Cada teste continha 2 etapas: carga e simulação de 20 terminais que realizam inserções, atualizações e exclusões.
A etapa de carga é executada pelo aplicativo de carga (load.exe), que insere dados em várias tabelas. Como você pode ver na figura 2, os dados são carregados com velocidades diferentes; varia de ~35Mb/seg a 1Mb/seg.
Figura 2. Velocidade de carga do banco de dados (gráfico vermelho)
Isso está relacionado ao design do aplicativo de carga, não ao Firebird: o carregador insere rapidamente 70% do banco de dados e depois preenche lentamente o restante dos dados, e isso se repete com bancos de dados de todos os tamanhos. É importante para nós que o carregador execute as mesmas operações, para que possamos usar sua velocidade média para medir a velocidade de carga.
É importante dizer que o carregador insere apenas dados, e os índices são criados após a conclusão da carga.
Vejamos a tabela com os resultados da etapa de carga para 11 bancos de dados entre 9 e 30Gb:
| # | tamanho do banco, gb | tempo de carga, seg | velocidade de carga SATA, Mb/seg |
|---|---|---|---|
| 1 | 9,04 | 2535 | 3,65166075 |
| 2 | 10,80 | 3197 | 3,45924304 |
| 3 | 13,00 | 4057 | 3,281242297 |
| 4 | 15,50 | 4698 | 3,378458919 |
| 5 | 17,30 | 5455 | 3,24751604 |
| 6 | 19,90 | 6037 | 3,375451383 |
| 7 | 21,60 | 6473 | 3,417024564 |
| 8 | 24,20 | 7539 | 3,287014193 |
| 9 | 26,00 | 7779 | 3,422547885 |
| 10 | 28,60 | 8851 | 3,308823862 |
| 11 | 30,30 | 9266 | 3,348499892 |
Figura 3. Tempo e velocidade de carga
Ou, é melhor mostrar no gráfico da figura 4:
Figura 4. Resultados do teste: velocidade de carga.
Como você pode ver, há um gráfico bastante estável, e a velocidade média do processo de carga varia em torno de 3.3-3.4Mb/seg. Também não há sinais de diminuição da velocidade de carga quando o tamanho do banco de dados se torna maior que o tamanho da RAM (após o banco de dados #5, com tamanho de 17.3Gb).
Desempenho
Então, os tempos de carga parecem bastante promissores, e quanto aos resultados reais de desempenho?
Antes de ir para os resultados de desempenho, vamos revisar rapidamente o processo de simulação.
A simulação executa 20 threads, e cada uma delas executa aleatoriamente várias operações de negócio: criar novo pedido, processar pagamento, contar produtos em estoque, processar entrega de pedido, etc (para detalhes, você pode ver os textos SQL das stored procedures reais). Como você pode ver, este é o conjunto usual de operações de negócio de um aplicativo abstrato de inventário/vendas.
O aplicativo de teste mede o número de operações de negócio por segundo e reporta um número médio. Claro, este número é um parâmetro artificial, mas é bom o suficiente para comparação.
Resultados do teste de desempenho:
| # | tamanho do banco, gb | desempenho no SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
Figura 5. Tabela com os resultados do teste de desempenho.
Ou, é melhor visualizar os resultados na representação gráfica:
Figura 6. Gráfico dos resultados de desempenho
Como você pode ver, há uma degradação lenta do desempenho com o crescimento do tamanho do banco de dados - quanto maior o banco de dados, mais lento ele funcionará (no mesmo hardware). Também não há grande queda de desempenho quando o tamanho do banco de dados se torna maior que a RAM. O crescimento do banco de dados de 9Gb para 30Gb leva a aproximadamente 20% de perda de desempenho.
Bancos de dados Firebird de 30Gb estão por toda parte agora, e eles crescem e crescem ao longo do tempo. No entanto, o que acontecerá com o desempenho do banco de dados quando ele for ainda maior? Queremos dizer - MUITO MAIOR! O que acontecerá com o desempenho quando o banco de dados se tornar REALMENTE GRANDE?
Sr. Grande
Para responder a essa pergunta, decidimos olhar para o final da tabela de testes e realizar um teste com um banco de dados de 1.7Tb (1813 Gb), no mesmo hardware, com as mesmas configurações.
Carga
Então, criamos esse banco de dados:
Figura 7. Tamanho do banco de dados - agora com 1813 Gb
A carga levou 566448 segundos - 157 horas, 6,55 dias. Isso é muito tempo, mas a velocidade média de carga foi… 3.28Mb/seg!
| # | tamanho do banco, gb | tempo de carga, seg | velocidade de carga SATA, Mb/seg |
|---|---|---|---|
| 12 | 1813,969025 | 566448 | 3,279214122 |
Figura 8. Tempo e velocidade de carga para o banco de dados Firebird de 1.7Tb
No gráfico, parece muito bom: o último ponto (#12). Então, o Firebird mostra resultados muito bons de seus algoritmos de inserção.
Figura 9. Velocidade de carga - ponto #12 é para o banco de dados Firebird de 1.7Tb
Desempenho do Sr. Grande
Então, executamos o mesmo teste de desempenho - a linha 12 é para o banco de dados de 1.7Tb.
| # | tamanho do banco, gb | desempenho no SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
| 12 | 1813,969025 | 169,33 |
Figura 10. Resultados do teste de desempenho - linha 12 é para o banco de dados de 1.7Tb
E no gráfico:
Figura 11. Desempenho, ponto #12 é para o banco de dados de 1.7Tb
O resultado confirma que há uma degradação lenta e estável do desempenho no Firebird - enquanto 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).
Não é uma situação comum quando o banco de dados (no mesmo hardware de baixo custo) cresce de 30Gb para 1.7Tb, mas o Firebird funcionará mesmo nessa situação.
Banco de dados grande em detalhes
Para entender melhor o banco de dados de 1.7Tb, coletamos estatísticas do banco de dados para o banco de dados Sr. Grande e analisamos no IBAnalyst:
Figura 12. Tabelas do banco de dados de 1.7Tb no IBAnalyst
Como você pode ver, há 2 tabelas grandes - ORDER_LINE (~600 Gb) com 6,3 bilhões de registros e STOCK (~680 Gb) com 2,1 bilhões de registros.
E, para essas tabelas, há 2 índices com profundidade = 4 - isso significa que cada solicitação faz 4 leituras de páginas de índice antes da leitura real dos dados. O índice ORDER_LINE_PK tem 50Gb de tamanho.
Figura 13. Índices do banco de dados Firebird de 1.7Tb
Apesar do enorme número de registros, as estatísticas do banco de dados parecem boas, então não é surpreendente que o Firebird mostre resultados bastante bons mesmo para um banco de dados grande em hardware de baixo custo.
Testando o Firebird com drive SSD
Após concluir a série de testes do Firebird em hardware de baixo custo, decidimos verificar quais seriam os resultados no outro extremo da tecnologia de armazenamento de dados e instalamos um drive SSD no mesmo servidor.
Instalamos o drive SSD Plextor PX-256M M5 Pro e executamos a mesma série de testes (exceto o banco de dados de 1.7Tb), com as mesmas configurações. Os resultados foram adicionados aos gráficos com dispositivos SATA, veja abaixo.
Carga
Como você pode ver, o tempo de carga no SSD é o mesmo que no SATA. Este é um resultado esperado: a velocidade das operações de escrita sequencial é quase a mesma em drives SATA e SSD.
Figura 14. Carga no SSD e SATA
Desempenho
Veja os resultados de desempenho:
Figura 15. Desempenho no SSD e SATA
Como você pode ver, o desempenho com operações de IO aleatórias mostra resultados ~8x melhores para o drive SSD. Sabíamos pela nossa experiência com bancos de dados de clientes que o SSD é 30-50% mais rápido com aplicativos do mundo real, mas um aumento de 8x é muito alto.
No entanto, este teste é artificial e especialmente projetado para simular operações OLTP de alta carga, com muitas atualizações/exclusões, mas sem grandes buscas. Um aplicativo de banco de dados comum não funciona nesse modo o tempo todo. Isso explica por que o SSD mostra resultados tão altos neste caso específico.
Resumo
Então, o que aprendemos com esses testes?
Em primeiro lugar - o desempenho do Firebird não tem grandes quedas relacionadas a alguma restrição de tamanho. No mesmo hardware, o desempenho diminuirá lentamente com o crescimento do tamanho do banco de dados. Essa diminuição de desempenho pode ser compensada com o ajuste da configuração do Firebird ou com uma atualização inteligente de hardware.
É um bom momento para mencionar que a IBSurgeon oferece serviço de otimização de desempenho do Firebird - usando dados experimentais que coletamos de testes como este, podemos aumentar significativamente o desempenho dos bancos de dados Firebird e InterBase.
Além disso, descobrimos que mesmo bancos de dados Firebird muito grandes (1,7 terabytes) funcionarão em hardware de baixo custo com perda de desempenho significativa, mas aceitável.
E terceiro, o SSD é realmente bom para aplicativos OLTP. Provavelmente é a maneira mais barata de melhorar o desempenho do banco de dados no momento. Claro, usar SSD não corrigirá problemas com planos de consulta ruins e índices ineficazes, mas pode aumentar o desempenho em geral.
Continuação: Mais detalhes sobre o banco de dados Firebird de 1,7 Terabyte.