Optimisation d'une base de données Firebird SQL de 1,7 téraoctet
Alexey Kovyazin, 14 juillet 2014
Comme vous vous en souvenez de nos articles précédents, nous avons étudié les mythes concernant la dégradation des performances de Firebird ( /fr/articles/firebird-performance-degradation-tests-myths-and-truth/), où nous avons créé plusieurs bases de données de 9 Go à 30 Go, et également testé une très grande base de données Firebird (1,7 téraoctet) (/fr/articles/more-details-about-1-7-terabyte-firebird-sql-database/).
Tous les tests ont été effectués sur le même matériel, qui est une configuration plutôt économique : CPU AMD-FX8350, 16 Go de RAM, RAID1 logiciel SATA 2x4To de disques durs Seagate, système d’exploitation Windows Server 2008R2 (2008R2 est en 64 bits), et avec la même configuration Firebird : Firebird 2.5.2 64 bits, SuperServer, avec des buffers de pages et TempCacheSize augmentés. Vous pouvez télécharger ce fichier de configuration SuperServer gratuitement à cette adresse : /fr/optimized-firebird-configuration/
En conséquence, nous avions l’image suivante des performances de la base de données :
Figure 1. Dégradation des performances de 9 Go à 30 Go, et 1,7 To
Le point #11 est une marque de performance pour la base de données de 30 Go et #12 pour la base de données de 1,7 téraoctet - 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).
Alors, la question est : pouvons-nous améliorer les performances de Firebird sur le même matériel avec un réglage de la configuration ?
Et la réponse est : oui !
Supercharger FirebirdSQL
Comme vous vous en souvenez, dans ce test, nous avons lancé 20 connexions simultanées qui effectuent des INSERTs intensifs et, moins intensivement, des UPDATEs.
Tous les SELECTs sont courts et bien définis, avec des plans d’exécution SQL efficaces, c’est donc une application OLTP (traitement transactionnel en ligne) typique. Pour de telles applications, la chose la plus critique pour les performances est le traitement parallèle. Firebird SuperServer 2.5.2 n’est pas bien adapté au traitement multi-thread - il n’utilise efficacement qu’un seul cœur par base de données, et ce fait fait de SuperServer un mauvais choix pour les applications OLTP.
Donc, nous devons changer l’architecture de Firebird vers Classic ou SuperClassic, qui prennent en charge le traitement multi-thread et utilisent plusieurs cœurs du CPU (il y a 8 cœurs dans le CPU AMD-FX8350).
Ensuite, quelques réglages sont nécessaires, car la configuration par défaut de Firebird n’est pas optimale pour notre système de test.
Paramètres de réglage dans firebird.conf
Cache de pages
Ainsi, afin d’améliorer les performances OLTP, nous avons décidé d’essayer les architectures Classic et SuperClassic. L’un des paramètres clés pour Classic et SuperClassic est le nombre de buffers de pages dans le cache. Contrairement à SuperServer, Classic et SuperClassic allouent le cache de pages par connexion.
Pour plus de détails sur les architectures Firebird en 2.5, vous pouvez consulter ce tableau : http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf
Il existe une formule simple pour calculer l’utilisation de la mémoire du cache de pages pour différentes architectures Firebird :
-
- SuperServer - un seul cache de pages par base de données. La taille par défaut du cache de pages est de 2048 pages, la recommandation mutuelle est de 10000 buffers. Dans notre cas, le cache était de 16k (taille de page) x 10000 ~= 160 Mo. C’est pour toutes les connexions.
-
- Classic et SuperClassic - le moteur alloue le cache de pages pour chaque connexion. La taille par défaut est de 75 pages, donc 16 Ko (taille de page) x 75 = ~= 1,17 Mo, pour chaque connexion.
Évidemment, la taille du cache de pages doit être augmentée, car 75 pages par connexion est trop peu. Nous montrerons ci-dessous les résultats de plusieurs valeurs différentes pour la taille du cache de pages.
LockHashSlots
En interne, le moteur Firebird utilise une table de verrous pour demander et acquérir des verrous sur les objets internes de la base de données, et pour Classic et SuperClassic, il existe le paramètre LockHashSlots (valeur par défaut 1009). Il doit être augmenté sous forte charge, pour réduire les chaînes de hachage dans la table de verrous. Eh bien, « forte charge » semble être toute application multi-utilisateurs réelle, nous l’avons donc défini à 30011 (pour tous les tests).
LockMemSize
Le paramètre LockMemSize est utilisé pour définir la taille initiale de la table de verrous (valeur par défaut 1048576). Le moteur peut augmenter la taille de la table à la demande. Cependant, l’augmentation de la table de verrous est coûteuse en termes de CPU et d’autres ressources, car elle est effectuée via un remappage de la mémoire. Nous l’avons donc défini à 7 Mo, afin d’économiser du temps et des ressources CPU.
Exécutions de tests
Nous avons effectué plusieurs exécutions de tests avec différentes valeurs de cache de pages, avec les résultats suivants :
| Buffers de pages | Classic, points de test | SuperClassic, points de test |
|---|---|---|
| 256 | 299 | 372 |
| 512 | 371 | 359 |
| 768 | 362 | 386 |
| 1024 | 312 | 387 |
| 1500 | 390 | 392 |
| 2048 | 285 | 284 |
Tableau 1. Exécutions de tests pour Classic et SuperClassic
Comme vous pouvez le voir, Classic et SuperClassic sont beaucoup plus efficaces que Firebird SuperServer pour cette tâche : les résultats des tests sont passés de 169 points à 300-400, ce qui est proche des résultats que nous avions pour la base de données de 30 Go !
Il est préférable de voir les résultats sur le graphique suivant :
Figure 2. Résultats des tests pour la base de données de 1,7 téraoctet
Vous pouvez voir que les meilleures performances (à la fois en Classic et en SuperClassic) étaient à 1500 pages par connexion, donc la taille du cache de pages par connexion était :
1500x16k ~= 23,4 Mo
Avec 2000 pages par connexion, les performances ont considérablement diminué. Il semble qu’aux alentours de 1500-2000 pages, l’avantage de la mise en cache est devenu inférieur aux frais généraux causés par les interactions de la table de verrous entre les processus pour synchroniser les pages dans les caches de chaque processus serveur. Évidemment, pour un nombre plus élevé de connexions, cela se produira plus tôt, c’est pourquoi les serveurs Classic/SuperClassic sont généralement configurés avec des nombres comme 256-512 pages.
Il y a aussi une baisse des performances de Classic autour de 768-1000 caches de pages - je ne suis pas sûr de la raison.
Résumé
Nos expériences confirment que les performances de Firebird peuvent être augmentées avec une sélection correcte de l’architecture Firebird (SuperServer, Classic ou SuperClassic) et avec un réglage approprié de plusieurs paramètres importants pour l’architecture spécifique.
En conséquence, une énorme base de données Firebird SQL de 1,7 To peut fonctionner sur du matériel bas de gamme avec des performances suffisamment bonnes. Comme résultat pratique de ces tests, nous avons créé plusieurs fichiers de configuration pour toutes les versions de Firebird pour toutes les architectures. Bien sûr, ils ne sont pas réglés pour l’application et/ou le matériel spécifiques, mais ils sont meilleurs que les fichiers de configuration par défaut, qui sont conçus pour une charge très modeste.
Ensemble complet de fichiers de configuration Firebird optimisés : /fr/optimized-firebird-configuration/
N’hésitez pas à poser des questions : [email protected]
Et ensuite ?
Nous travaillons sur un test complet qui comparera les performances de Firebird 2.5 et Firebird 3.0, avec une simulation réaliste de charge et un grand nombre de connexions. Restez à l’écoute !