Cette page a été traduite automatiquement. Lisez l'original en anglais. English

Bibliothèque IBSurgeon

Comment faire fonctionner Firebird 20 % plus rapidement sur Windows Server 2016 en moins d’1 minute

De plus en plus d’utilisateurs passent à Windows Server 2016 depuis d’anciennes versions, et certains d’entre eux ont remarqué que Windows Server 2016 fonctionne plus lentement que les versions précédentes, même sur le même matériel avec la même base de données.

Nous avons effectué plusieurs tests sur Windows Server 2016 et Firebird, et avons découvert, entre autres, l’option qui influence considérablement les performances de Windows Server 2016 : le plan d’alimentation.

Par défaut, Windows 2016 dispose du plan d’alimentation « Équilibré », qui équilibre automatiquement les performances et la consommation d’énergie sur le matériel capable. Cela semble inoffensif, mais en réalité, le plan d’alimentation Équilibré sur Windows Server 2016 supprime considérablement les performances du CPU et diminue les performances globales du serveur.

Il est possible de changer le plan d’alimentation à la volée, sans redémarrage. Voyez l’effet de l’activation du plan « Haute performance » sur le serveur avec la base de données Firebird, qui sert 70 connexions :

Effet du plan d’alimentation Haute performance sur l’utilisation du CPU

Bon, cela peut n’être qu’une question d’utilisation du CPU, qu’en est-il des performances globales ? Nous avons exécuté plusieurs tests, similaires à TPCC (simulation d’application OLTP) et avons obtenu ces chiffres :

Plan d’alimentation Débit TPC-C (plus c’est élevé, mieux c’est)
Équilibré 17029
Haute performance 21226

Ce test est fortement limité par le disque, donc la différence n’est que de 20 %, pour les opérations intensives en CPU, l’amélioration peut être encore plus élevée.

De plus, nous avons effectué le test de restauration (avec gbak -c) d’une base de données Firebird 2.5 de 144 Go avec différents plans d’alimentation :

Plan d’alimentation Temps de restauration (moins c’est mieux)
Équilibré 4 heures 7 minutes
Haute performance 2 heures 35 minutes

La simple option « économie d’énergie » a presque doublé les performances de restauration ! Pourquoi avons-nous une augmentation de performances aussi notable ? La réponse se trouve dans les index : pendant la restauration, ils utilisent intensivement le CPU pour trier les valeurs.

Regardez les valeurs de timestamps de la restauration gbak (en secondes) pour les 5 plus grands index.

Avec le plan d’alimentation équilibré gbak :

Code
gbak: 9529.339 1230.343 5028900 346529     activating and creating deferred index INDMF_TAG_PLC_DATA_DT_D
gbak: 10787.610 1258.270 5028909 233365     activating and creating deferred index INDMF_TAG_PLC_DATA_TAG_D
gbak: 11824.329 1036.718 5028907 216488     activating and creating deferred index INDMF_TAG_PLC_DATA_LU_D
gbak: 12571.012 746.683 5028907 265160     activating and creating deferred index INDMF_TAG_PLC_DATA_C1
gbak: 13304.334 733.321 5028908 359393     activating and creating deferred index PKMNF2_DOC_DOWNTIME

Temps total : 3775 secondes

Avec le plan d’alimentation Haute performance

gbak: 5301.785 615.045 5028900 346529 activating and creating deferred index INDMF_TAG_PLC_DATA_DT_D

Code
gbak: 5924.667 622.882 5028909 233365     activating and creating deferred index INDMF_TAG_PLC_DATA_TAG_D
gbak: 6569.815 645.147 5028907 216488     activating and creating deferred index INDMF_TAG_PLC_DATA_LU_D
gbak: 7186.322 616.506 5028907 265160     activating and creating deferred index INDMF_TAG_PLC_DATA_C1
gbak: 7894.340 708.018 5028908 359393     activating and creating deferred index PKMNF2_DOC_DOWNTIME

Temps total : 2593 secondes

Résumé

Ainsi, ce simple paramètre dans Panneau de configuration -> Matériel et audio -> Options d’alimentation peut grandement améliorer les performances de la base de données Firebird sur Windows Server 2016.

Veuillez le vérifier et activer le plan d’alimentation Haute performance immédiatement !

Pour en savoir plus sur les performances des bases de données Firebird :

Remerciements particuliers à Oleg Matveev pour son aide dans la préparation de cet article !