Un nouveau script d'import OCS a été développé.
Il permet de :
Il permet de :
- gérer les imports et synchronisations de machines via un seul script
- d'accélerer les performances de l'import en lançant plusieurs threads en même temps
- un script shell qui lance les threads
- une page php qui réalise un import
Syntaxe¶
Le script s'appelle ocsng_fullsync.sh. Il prend les paramètres suivants :- server_id : l'ID du serveur OCS pour lequel le script va s'exécuter. Si ce paramètre est omis, le script synchronisera tous les serveurs OCS renseignés dans GLPI
- thread_nbr : indique le nombre de threads qui seront lancés en simultanés
Exemple de synchronisation du serveur dont l'ID est 1 en utilisant 3 threads :
*Attention :* Le script utilisant le mécanisme de cache de GLPI, il doit avoir un accès en écriture sur les fichiers du cache (files/_cache). Il faut donc bien faire attention à l'utilisateur Unix qui va lancer le script ! h2. Fonctionnement du script L'import et la synchro sont répartis sur n threads. Il est possible, bien sûr, de préciser un seul thread. Le script utilise les modulos pour déterminer quelles seront les machines synchronisées par un thread. Exemple : si l'on lance le script avec 3 threads, chaque thread va lancer une requête SQL avec comme clause AND : ** AND ID % 3 = 2 ** AND ID % 3 = 1 ** AND ID % 3 = 0 Grâce à ce mécanisme, on est sûr que 2 threads ne synchroniseront pas la même machine. [[Image(ocs_import_script_fr.png)]] h3. Mécanisme de lock Le script gère un mécanisme de lock, suivant la cynématique suivante : ** un thread récupère un ID de machine OCS à importer ** le moteur de règle détermine à quelle entité la machine doit être affectée ** la machine doit être importée dans l'entité XX ** un lock est posé par le thread sous la forme d'un fichier lock_entity_XX qui se trouve dans le répertoire (files/_lock) ** GLPI importe la machine ** le lock est retiré Si un autre thread veut, au même moment, importer une autre machine pour la même entité, celui-ci ne pourra pas acquérir le lock pour cette entité, et attendra jusqu'à ce que celui-ci soit enlevé. Ce mécanisme permet de : ** gérer les imports simultanés ** ne pas avoir de doublons dans la base h3. Evaluation du nombre de threads à lancer Le choix du nombre de threads doit être pris en fonction de la puissance de votre machine. En effet, si vous exécutez le script avec un trop grand nombre de threads, vous pouvez facilement écrouler les performances générales de la machines (et donc de GLPI). Il est bien sûr possible de lancer le script avec un seul thread, ce qui permet de reproduire le comportement de l'import à l'heure actuelle (avec les scripts ocs_mass_import.php et ocs_mass_sync.php). Pour déterminer le nombre de thread acceptable, il est préférable de : * réaliser des tests d'imports avec plusieurs valeurs de threads différents * comparer les résultats (cela permet de voir le nombre de machines importées/secondes) * comparer les performances des différents logiciels pendant l'import (php, mysql etc...) jusqu'à trouver des valeurs qui n'empêchent pas la bonne utilisation de l'application h3. Performances Les tests ont été effectués avec une version 0.70, comportant 18 entités et 20 règles d'affectation. Voici quelques chiffres, fournis à titre indicatifs : *Athlon XP, 1 processeur*: * Athlon XP 2800+ * 1Go de RAM * OS: Debian * import de 1013 machines Résultats : * 2 threads simultanés : 6m25 soit 2,7 machines par secondes * 3 threads simultanés : 8m27 soit 1,99 machines par secondes La machine étant monoprocesseur, il vaut mieux limiter le nombre de threads. *Octo Xeon 3Ghz*: * 2 Xeons quadri-coeurs * 4Go de RAM * OS: Fedora Core 6 * import de 1013 machines Résultats : * 6 threads simultanés : 1m29sec * 8 threads simultanés : 1m17sec * 9 threads simultanés : 1m12sec * 10 threads simultanés : 1m6sec * 12 threads simultanés : 1m07sec * 16 threads simultanés : 1m07sec Le meilleur compromis est de lancer entre 8 et 10 threads, ce qui permet d'avoir un rendement maximum sans écrouler les performances de la machine.
