L'indexation JIRA - Valiantys - Atlassian Platinum Partner
logo-bleu_rvb.png
Back

L’indexation JIRA

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 !

Cutted Triangle

Subscribe to the Valiantys Newsletter

Demande enregistrée ! Demande en cours... Ceci n'est pas un email Une erreur s'est produite

In accordance with our privacy policy, we are committed to respecting your personal data.

Contact us

Our Atlassian certified consultants will be happy to answer you.

Join us

We're building the next dream team - Are you in?

Follow us

Nous utilisons des cookies pour le fonctionnement de ce site, pour améliorer son utilisation, personnaliser votre expérience et réaliser des statistiques de visite. Vous pouvez gérer les paramètres et choisir d’accepter ou non certains cookies durant votre navigation. Pour plus d’informations, consultez notre politique de confidentialité. Nos politique de confidentialité

Paramètres de confidentialité

Afin de faciliter votre navigation et de vous apporter le meilleur service possible, nous utilisons des cookies pour améliorer le site aux besoins des visiteurs, notamment selon la fréquentation.  Pour plus d’informations, consultez notre politique de confidentialité. Nos politique de confidentialité

Recaptcha

Google reCAPTCHA est un système conçu pour distinguer les humains des ordinateurs, de telle sorte que les bots soient incapables de remplir les formulaires de manière malveillante au nom d’un être humain.

Analytics

Utilisé pour envoyer des données à Google Analytics sur le périphérique et le comportement du visiteur. Suit l'internaute à travers les appareils et les canaux de marketing. Utilisé par Google Analytics pour diminuer radicalement le taux de requêtes. Enregistre un identifiant unique utilisé pour générer des données statistiques sur la façon dont le visiteur utilise le site.

LinkedIn

Cookies pour une publicité ciblée : Ces cookies peuvent être mis en place au sein de notre site Web par nos partenaires publicitaires. Ils peuvent être utilisés par ces sociétés pour établir un profil de vos intérêts et vous proposer des publicités pertinentes sur d'autres sites Web. Ils ne stockent pas directement des données personnelles, mais sont basés sur l'identification unique de votre navigateur et de votre appareil Internet. Si vous n'autorisez pas ces cookies, votre publicité sera moins ciblée.

Cookies "réseaux sociaux" : Ces cookies sont activés par les services proposés sur les réseaux sociaux que nous avons ajoutés au site Web afin de vous donner la possibilité de partager notre contenu avec votre réseau et vos connaissances. Ils nous permettent également de suivre votre navigation sur d’autres sites Web et d’établir un profil de vos intérêts. Cela peut avoir un impact sur le contenu et les messages affichés sur les autres sites Web que vous consultez. Si vous n'autorisez pas ces cookies, il se peut que vous ne puissiez pas utiliser ou visualiser ces outils de partage.