Forums de support technique relatifs à UltraBackup et UltraBackup NetStation
Vous n'êtes pas identifié.
Bonjour,
Une petite question sur les performances FireBird.
Configuration Serveur:
Windows 2003 Server
Bi-Xéon 2GHz (2x4 cœurs)
4 Go de RAM
UBNS2 (2.2.75)
Ce serveur sert à sauvegarder 14 machines qui ont chacune 7 sauvegardes (donc 98 sauvegardes en tout).
Cela représente un peu plus de 600 000 fichiers sauvegardés et il y a environ 30 000 créations/suppressions chaque nuit.
Je commence à rencontrer des problèmes de performance, car les sauvegardes durent de plus en plus longtemps (plages horaire de 5 heures la nuit, qui est actuellement dépassée)
En utilisant des sondes sur les processeurs et les accès disque, je m'aperçoit que les performances disques ne sont pas en cause mais plutôt le service "fbserver" qui ne tourne que sur un cœur et occupe donc 12.5% du CPU total.
D'où ma question:
Comment optimiser Firebird pour utiliser plus d'un coeur sur des systèmes muti-coeurs , la CPU de mon serveur de sauvegarde étant sous-utilisée ?
Cordialement,
Benjamin
Hors ligne
Bonjour,
La version intégrée à UB est une version dite "SuperServer", qui en attendant la v3 du SGBD (qu'ils prévoient pour la fin de l'année) ne semble pas optimisée pour les postes multi-coeur :
http://www.ibphoenix.com/main.nfs?a=ibp … AME='IFDP'
http://www.firebirdsql.org/manual/fr/qs … super.html
http://www.developpez.net/forums/d68367 … perserver/
Sans doute pouvez-vous tester l'installation d'une version "classic" 2.1.2, mais je n'ai personnellement jamais essayé. Une solution peut aussi consister en la modification du paramètre CpuAffinityMask dans les fichiers de configuration FB.
Néanmoins, pensez-vous à optimiser de temps en temps la base de données à l'aide des outils fournis avec UB ? Cela permet de compacter les enregistrements et donc d'augmenter significativement les performances d'une base fragmentée.
Cordialement,
A.R.
Hors ligne
Re bonjour,
La base est optimisée chaque nuit:
- 23h00, lancement des sauvegardes sur chaque machine (14 machines, 7 sauvegarde par machine lancée à la "queue leu leu").
- 04h00, arrêt du serveur de sauvegarde pour optimisation de la base et sauvegarde de la base et des comptes de stockage (environ 01h30).
J'avais vu le commutateur "CpuAffinityMask" dans le fichier de conf de FireBird mais je ne savais pas quelle version était utilisée (SuperServer ou classic).
Je vais essayer les deux options cet AM.
Je posterais les résultats
Hors ligne
OK, merci de votre retour !
Cordialement,
Hors ligne
Petit retour après quelques test:
- Le paramètre "CpuAffinityMask" pour la version SuperServer est catastrophique
En gros, le service fbserver reste limité à 12-13% de la CPU totale mais réparti sur tous les cœurs !! ?????
- L'utilisation de la version Classic donne un gain de performance significatif:
Sur une machine avec sept sauvegardes incrémentales et aucun fichier de transmis (les fichiers sont déjà à jours), la validation des sauvegardes passe de 30 minutes à quelques secondes !
En parallèle, le serveur de sauvegarde utilise entre 80% et 100% de la CPU totale (ce qu'on lui demande de faire).
Je vais donc conserver FireBird classic quelques jours pour le moment et regarder le gain de temps sur les sauvegarde nocturnes réelles.
Je posterais les résultats.
Merci.
Hors ligne
Bonjour,
Comme promis, voici mon retour sur le test du serveur de BDD en version "classic".
Test effectué en réel, 14 machines utilisées, 7 sauvegardes par machine lancées les unes après les autres.
Le serveur de sauvegarde contient un peu plus de 600 000 fichiers et environ 30 000 fichiers ont été supprimés/ajoutés cette nuit.
Les sauvegardes ont commencé à 23h00 et la dernière c'est terminée à 00:24 soit 1h24 au total pour 98 travaux.
Pour rappel, avec la version "superserver" de firebird, le processus ne tourne que sur un cœur (sur huit disponibles) et les 98 travaux mettaient plus de 6 heures !
Je vais donc conserver la version "classic" pour le moment.
BC
Hors ligne
Très bien, merci de votre retour... Nous sommes en train de construire la documentation pour notre nouveau site et ces informations pourront alimenter une section dédiée au support de configurations à grosse volumétrie.
Hors ligne