Dégradation des performances de Firebird : tests, mythes et vérité
Alexey Kovyazin, 16 mai 2014
Vous pouvez télécharger cet article au format PDF.
Récemment, chez IBSurgeon, nous avons effectué une série de tests de performance avec Firebird 2.5.2. Firebird 2.5.2 est la version la plus populaire de la base de données Firebird, et ses utilisateurs ont souvent des questions liées aux performances de Firebird.
L’une des préoccupations les plus importantes concernant les performances de la base de données est sa dégradation. De nombreux utilisateurs affirment que leurs applications de base de données rencontrent des problèmes de performances lorsqu’elles atteignent une certaine valeur seuil : cela peut être 3 Go, 5 Go, la taille de la RAM, 20 Go, etc. La revendication la plus courante est « la taille de la base de données est supérieure à la taille de la RAM » : lorsque la taille de la base de données Firebird atteint la taille de la RAM, il est rapporté qu’elle devient très lente… Est-ce vrai ?
Nous avons décidé d’effectuer une série de tests pour vérifier s’il existe une telle dégradation des performances liée à la croissance de la base de données. Nous avons décidé de simuler la croissance de la base de données sur toute sa durée de vie avec la même charge sur le même matériel, et pour cela nous avons exécuté 11 tests avec des bases de données dont la taille varie entre 9 Go et 30 Go :
Figure 1. Tailles des bases de données pour les tests
Matériel de test et configuration Firebird
Le matériel de test avait les caractéristiques clés suivantes :
CPU AMD-FX8350, RAM 16 Go, RAID1 logiciel SATA 2x4To disques Seagate, système d’exploitation Windows Server 2008R2 (2008R2 est 64 bits).
Comme vous pouvez le voir, c’est une configuration matérielle d’entrée de gamme ; elle peut être achetée pour moins de 1000 USD actuellement (mai 2014), et elle peut être considérée comme une configuration typique de bas niveau - peut-être, à l’exception des grands disques SATA, mais selon le rapport du fabricant, la vitesse des disques SATA de 1 To et 4 To est presque la même.
Comme l’objectif du test était de mesurer les changements de performances d’un système typique, nous avons utilisé Firebird (64 bits) avec l’architecture SuperServer, et non Classic, pour simuler complètement la situation d’une petite entreprise - ils utilisent ce qui a été installé à l’origine pendant des années. Comme vous le savez, SuperServer n’utilise qu’un seul cœur de CPU, donc probablement Classic ou SuperClassic (qui peuvent utiliser tous les cœurs du CPU) pourraient montrer de meilleurs résultats en termes de performances, mais notre objectif n’était pas le réglage des performances.
Cependant, nous avons ajusté firebird.conf avec les changements évidents que nous recommandons pour toutes les installations Firebird SuperServer : augmentation des buffers de pages à 10000 et de l’espace temporaire pour le tri.
Toutes les bases de données de test ont été créées avec une taille de page de 16384, juste pour la cohérence.
Tests
Chargement
Chaque test comprenait 2 étapes : le chargement et la simulation de 20 terminaux qui effectuent des insertions, des mises à jour et des suppressions.
L’étape de chargement est effectuée par une application de chargement (load.exe), qui insère des données dans plusieurs tables. Comme vous pouvez le voir sur la figure 2, les données sont chargées à des vitesses différentes ; cela varie de ~35 Mo/sec à 1 Mo/sec.
Figure 2. Vitesse de chargement de la base de données (graphique rouge)
Cela est lié à la conception de l’application de chargement, et non à Firebird : le chargeur insère rapidement 70 % de la base de données puis remplit lentement le reste des données, et cela est répété avec des bases de données de toutes tailles. Il est important pour nous que le chargeur effectue les mêmes opérations, afin que nous puissions utiliser sa vitesse moyenne pour mesurer la vitesse de chargement.
Il est important de mentionner que le chargeur insère uniquement des données, et les index sont créés après la fin du chargement.
Regardons le tableau des résultats de l’étape de chargement pour 11 bases de données entre 9 et 30 Go :
| # | taille de la base de données, Go | temps de chargement, sec | vitesse de chargement SATA, Mo/sec |
|---|---|---|---|
| 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 |
Figure 3 Temps et vitesse de chargement
Ou, il est préférable de le montrer sur le graphique de la figure 4 :
Figure 4. Résultats des tests : vitesse de chargement.
Comme vous pouvez le voir, le graphique est assez stable, et la vitesse moyenne du processus de chargement varie autour de 3,3-3,4 Mo/sec. Il n’y a également aucun signe de diminution de la vitesse de chargement lorsque la taille de la base de données devient supérieure à la taille de la RAM (après la base de données #5, avec une taille de 17,3 Go).
Performances
Donc, les temps de chargement semblent assez prometteurs, qu’en est-il des résultats de performances réels ?
Avant d’aborder les résultats de performances, examinons rapidement le processus de simulation.
La simulation exécute 20 threads, et chacun d’eux exécute aléatoirement plusieurs opérations métier : créer une nouvelle commande, traiter un paiement, compter les produits en stock, traiter la livraison d’une commande, etc. (pour plus de détails, vous pouvez consulter les textes SQL des procédures stockées réelles). Comme vous pouvez le voir, c’est un ensemble habituel d’opérations métier d’une application abstraite d’inventaire/ventes.
L’application de test mesure le nombre d’opérations métier par seconde et rapporte un nombre moyen. Bien sûr, ce nombre est un paramètre artificiel, mais il est suffisant pour la comparaison.
Résultats des tests de performance :
| # | taille de la base de données, Go | performance sur 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 |
Figure 5. Tableau des résultats des tests de performance.
Ou, il est préférable de visualiser les résultats sous forme graphique :
Figure 6. Graphique des résultats de performance
Comme vous pouvez le voir, il y a une lente dégradation des performances avec la croissance de la taille de la base de données - plus la base de données est grande, plus elle fonctionnera lentement (sur le même matériel). Il n’y a également pas de forte chute des performances lorsque la taille de la base de données devient supérieure à la RAM. La croissance de la base de données de 9 Go à 30 Go entraîne environ 20 % de perte de performance.
Les bases de données Firebird de 30 Go sont courantes de nos jours, et elles grandissent et grandissent avec le temps. Cependant, que se passera-t-il avec les performances de la base de données lorsqu’elle sera encore plus grande ? Nous voulons dire - ENCORE PLUS GRANDE ! Que se passera-t-il avec les performances lorsque la base de données deviendra VRAIMENT GRANDE ?
Mr.Big
Pour répondre à cette question, nous avons décidé de regarder tout à la fin du tableau de test et d’effectuer un test avec une base de données de 1,7 To (1813 Go), sur le même matériel, avec les mêmes paramètres.
Chargement
Donc, nous avons créé une telle base de données :
Figure 7. Taille de la base de données - maintenant avec une base de données de 1813 Go
Le chargement a pris 566448 secondes - 157 heures, 6,55 jours. C’est long, mais la vitesse moyenne de chargement était… 3,28 Mo/sec !
| # | taille de la base de données, Go | temps de chargement, sec | vitesse de chargement SATA, Mo/sec |
|---|---|---|---|
| 12 | 1813,969025 | 566448 | 3,279214122 |
Figure 8. Temps et vitesse de chargement pour la base de données Firebird de 1,7 To
Sur le graphique, cela semble très bien : le dernier point (#12). Donc, Firebird montre de très bons résultats de ses algorithmes d’insertion.
Figure 9 Vitesse de chargement - le point #12 concerne la base de données Firebird de 1,7 To
Performance de Mr.Big
Ensuite, nous avons exécuté le même test de performance - la ligne 12 concerne la base de données de 1,7 To.
| # | taille de la base de données, Go | performance sur 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 |
Figure 10. Résultats des tests de performance - la ligne 12 concerne la base de données de 1,7 To
Et sur le graphique :
Figure 11. Performance, le point #12 concerne la base de données de 1,7 To
Le résultat confirme qu’il y a une dégradation lente et stable des performances dans Firebird - tandis que la taille de la base de données a été multipliée par 60 (de 30 Go à 1813 Go), la perte de performance était de 2,4 fois (de 407 à 169 points).
Ce n’est pas une situation courante où une base de données (sur le même matériel d’entrée de gamme) passe de 30 Go à 1,7 To, mais Firebird fonctionnera même dans cette situation.
Grande base de données en détail
Pour mieux comprendre la base de données de 1,7 To, nous avons recueilli les statistiques de la base de données pour la base Mr.Big et les avons analysées dans IBAnalyst :
Figure 12 Tables de la base de données de 1,7 To dans IBAnalyst
Comme vous pouvez le voir, il y a 2 grandes tables - ORDER_LINE (~600 Go) avec 6,3 milliards d’enregistrements et STOCK (~680 Go) avec 2,1 milliards d’enregistrements.
Et, pour ces tables, il y a 2 index avec une profondeur = 4 - cela signifie que chaque requête effectue 4 lectures de pages d’index avant la lecture réelle des données. L’index ORDER_LINE_PK a une taille de 50 Go.
Figure 13. Index de la base de données Firebird de 1,7 To
Malgré le nombre énorme d’enregistrements, les statistiques de la base de données semblent bonnes, il n’est donc pas surprenant que Firebird montre de très bons résultats même pour une grande base de données sur du matériel d’entrée de gamme.
Test de Firebird avec un disque SSD
Après avoir terminé la série de tests Firebird sur du matériel d’entrée de gamme, nous avons décidé de vérifier quels seraient les résultats à l’autre extrémité de la technologie de stockage de données et avons installé un disque SSD sur le même serveur.
Nous avons installé un disque SSD Plextor PX-256M M5 Pro et exécuté la même série de tests (sauf la base de données de 1,7 To), avec les mêmes paramètres. Les résultats ont été ajoutés aux graphiques avec les périphériques SATA, voir ci-dessous.
Chargement
Comme vous pouvez le voir, le temps de chargement sur SSD est le même que sur SATA. C’est un résultat attendu : la vitesse des opérations d’écriture séquentielle est presque la même sur les disques SATA et SSD.
Figure 14. Chargement sur SSD et SATA
Performances
Voir les résultats de performance :
Figure 15. Performance sur SSD et SATA
Comme vous pouvez le voir, la performance avec des opérations d’E/S aléatoires montre des résultats ~8x meilleurs pour le disque SSD. Nous savions par notre expérience avec les bases de données des clients que le SSD est 30 à 50 % plus rapide avec des applications réelles, mais une augmentation de 8x est très élevée.
Cependant, ce test est artificiel et spécialement conçu pour simuler des opérations OLTP à forte charge, avec de nombreuses mises à jour/suppressions, mais sans grandes lectures. Une application de base de données habituelle ne fonctionne pas tout le temps dans ce mode. Cela explique pourquoi le SSD montre des résultats aussi élevés dans ce cas particulier.
Résumé
Alors, qu’avons-nous appris de ces tests ?
Tout d’abord - la performance de Firebird n’a pas de grandes diminutions liées à une restriction de taille. Sur le même matériel, la performance diminuera lentement avec la croissance de la taille de la base de données. Cette diminution de performance peut être compensée par un réglage de la configuration Firebird ou par une mise à niveau matérielle intelligente.
C’est un bon endroit pour mentionner qu’IBSurgeon propose un service d’optimisation des performances Firebird - en utilisant les données expérimentales que nous avons recueillies lors de tests comme celui-ci, nous pouvons augmenter considérablement les performances des bases de données Firebird et InterBase.
Ensuite, nous savions que même de très grandes bases de données Firebird (1,7 téraoctets) fonctionneront sur du matériel d’entrée de gamme avec une perte de performance significative, mais acceptable.
Et troisièmement, le SSD est vraiment bon pour les applications OLTP. C’est probablement le moyen le moins cher d’améliorer les performances de la base de données actuellement. Bien sûr, l’utilisation d’un SSD ne résoudra pas les problèmes de mauvais plans de requêtes et d’index inefficaces, mais cela peut augmenter les performances en général.
À suivre : Plus de détails sur la base de données Firebird de 1,7 téraoctet.