L’application JIRA sollicite énormément la base de données. Afin de soulager celle-ci et de permettre à l’utilisateur de bénéficier d’une meilleure réactivité, l’application s’appuie sur une bibliothèque open source appelée Lucene qui récupère le contenu désiré de la base de données et le conserve sous forme de fichiers sur le serveur d’application. Cette solution a l’avantage de ne pas être dépendante du réseau ou du serveur de base de données. En contrepartie, elle nécessite de l’espace disque et une mise à jour systématique des indexes à chaque modification de demande.
Voyons plus en détail le principe de la réindexation, et les différentes possibilités qui s’offrent à nous pour ré-indexer l’application.
Principe
Dans JIRA, les indexes sont essentiellement utilisés dans les recherches, ce qui améliore considérablement les performances par rapport à une recherche en base de données. JIRA nous invite à ré-indexer dès que nous réalisons une modification de configuration d’un champ ou d’un composant additionnel (parce qu’il peut apporter un nouveau type de champ) car le résultat des recherches peut être impacté par cette modification. Plus la volumétrie de l’application est importante, plus le gain de performances imputable aux indexes est important.
Il est important de planifier une réindexation complète de manière récurrente car le résultat de celle-ci est plus performant que des indexes construits au fil de l’eau. En effet, une reconstruction totale des indexes permet un meilleur regroupement et une meilleure compression des données.
Il existe plusieurs possibilités pour ré-indexer l’application, chacune ayant ses spécificités.
La réindexation en arrière plan
Ce type de ré-indexation est disponible à partir de la version 5.2 de JIRA et peut être utilisé dans la majorité des cas. En particulier lors d’une modification de configuration car il n’empêche pas les utilisateurs de travailler. Cependant ce type de ré-indexation ne reconstruit pas totalement les indexes, il modifie les indexes existants. Les indexes concernant l’historique et les commentaires des demandes ne sont pas reconstruits. Cette réindexation peut être annulée à tout moment. Elle est déconseillée pour les instances à forte volumétrie car elle peut durer plusieurs heures pendant lesquelles l’application est “moins” performante.
La réindexation complète
Elle est obligatoire lorsque les indexes ont été corrompus. Une corruption d’index est causé par un arrêt inopiné de l’application, un problème de disque, un composant additionnel présentant un défaut de conception, … Lorsque l’on constate une différence entre le résultat d’une recherche et le véritable état d’une demande, il s’agit d’une corruption d’index. Ce type de réindexation supprime les indexes existants et reconstruit entièrement ceux-ci, le résultat obtenu est plus performant que celui obtenu à l’aide d’une réindexation en arrière plan. Le délai de construction des indexes est plus court qu’une réindexation en arrière plan mais l’application est verrouillée pendant le processus et les utilisateurs ne peuvent pas utiliser l’application.
La réindexation d’un projet
Il s’agit d’une réindexation en arrière plan limitée à un projet. Elle doit être utilisée pour les mêmes raisons que son aînée lorsque la modification de configuration n’impacte qu’un seul projet.
Optimiser la réindexation
Alors que les indexes sont vitaux sur les instances à forte volumétrie, le délai de réindexation peut s’avérer particulièrement bloquant. Ce délai dépend essentiellement du nombre de demandes et du nombre de champs personnalisés. Par exemple, il est courant de dépasser l’heure de réindexation pour les instances de plus de 500 000 demandes. Pour ces instances, la réindexation en arrière plan est souvent inutile car elle peut durer plusieurs heures, et dans certains cas rendre l’application inutilisable. Or, ces instances sont souvent critiques et utilisées internationalement, auquel cas il est difficile de planifier une interruption de service de plus d’une heure pour chaque modification de configuration.
Il est alors indispensable d’optimiser le processus de réindexation pour réduire ce temps d’interruption. La configuration par défaut de JIRA n’est pas dimensionnée pour les serveurs hébergeant autant de demandes et ces serveurs sont souvent sous-utilisés pendant une réindexation. Nous allons donc modifier ces paramètres afin d’utiliser au maximum les capacités de notre serveur et réduire ainsi le temps d’indexation.
Les paramètres sur lesquels nous pouvons agir sont les suivants :
| Paramètre | Valeur par défaut | Description | Commentaire |
| jira.index.issue.maxqueuesize | 1000 | Le nombre maximum de demandes présentes dans la file de réindexation | Cette valeur doit être adaptée au nombre de processus utilisés pour la réindexation. Par défaut, on assigne au maximum 100 demandes à chaque processus (1000 demandes pour 10 processus). |
| jira.index.issue.minbatchsize | 50 | Le nombre minimal de demandes devant être présentes dans la file pour activer le traitement sur plusieurs processus (multi-thread) | Cette valeur définit le seuil d’activation du traitement en mode multi-processus. Dans notre cas elle est triviale. Cependant, elle ne doit pas être supérieure à la taille de la file. |
| jira.index.issue.threads | 10 | Le nombre de processus à utiliser pour la réindexation des demandes | Il s’agit de la valeur la plus impactante sur la durée de traitement de la réindexation. Elle doit être modifiée avec attention afin de ne pas surcharger le serveur. Elle doit être adaptée au nombre de cœurs et de processeurs possédés par le serveur. |
| jira.index.sharedentity.maxqueuesize | 1000 | Le nombre maximum d’objets partagés (filtres, tableaux de bord…) présents dans la file de réindexation | Cette valeur doit être adaptée au nombre de processus utilisés pour la réindexation. Par défaut, on assigne au maximum 100 filtres à chaque processus (1000 demandes pour 10 processus). |
| jira.index.sharedentity.minbatchsize | 50 | Le nombre minimal d’objets partagés devant être présents dans la file pour activer le traitement sur plusieurs processus (multi-thread) | Cette valeur définit le seuil d’activation du traitement en mode multi-processus. Dans notre cas elle est triviale. Cependant, elle ne doit pas être supérieure à la taille de la file. |
| jira.index.sharedentity.threads | 10 | Le nombre de processus à utiliser pour la réindexation des objets partagés | Il s’agit de la valeur la plus impactante sur la durée de traitement de la réindexation. Elle doit être modifiée avec attention afin de ne pas surcharger le serveur. Elle doit être adaptée au nombre de cœurs et de processeurs possédés par le serveur. |
Ces paramètres peuvent être ajoutés directement dans le fichier “jira-config.properties”. Ils sont disponibles à partir de la version 5.2 de JIRA.
De manière générale :
- Augmenter la taille de la file réduit le nombre de sollicitation du serveur de base de données mais augmente la charge de travail du processeur par processus, et inversement.
- Augmenter le nombre de processus augmente la charge du serveur de base de données et du serveur applicatif.
Il convient d’adapter ces paramètres en fonction de l’environnement afin de déterminer les paramètres de manière optimale. Les autres facteurs limitant peuvent être les temps d’accès aux disques durs et la rapidité du réseau entre le serveur applicatif et le serveur de base de données.
Planifier une réindexation
Afin d’éviter une interruption de service aux heures de travail, il est intéressant de pouvoir planifier une réindexation. Depuis la version 6.1 de JIRA, il existe une API REST qui offre la possibilité de réaliser une réindexation à l’aide d’un simple appel HTTP. Nous allons utiliser cette API pour réaliser un script Unix capable de lancer une réindexation.
#!/bin/sh
# Params
username=admin
password=admin
baseURL=http://localhost:8080
reindexAPI="/rest/api/2/reindex"
# Generate credentials
credentials=$(printf $username:$password | base64)
# Call URL
curl -s -X POST -H "Authorization: Basic $credentials" -H "Cache-Control: no-cache" -H "X-Atlassian-Token: no-check" $baseURL$reindexAPI?type=FOREGROUND >> /dev/null
Si vous avez des questions ou des suggestions sur l’indexation JIRA, n’hésitez pas à les partager en commentaire !
