Optimisation des Performances Jenkins : Un Guide Complet de Gestion des Ressources

L'optimisation des performances de Jenkins commence généralement après que les gens sont déjà agacés : les pull requests restent dans la file d'attente, l'interface hésite, les builds échouent avec d'étranges erreurs d'agent, ou le contrôleur a besoin d'un autre redémarrage. La solution est rarement un seul flag JVM magique. Jenkins est un coordinateur plus une flotte de machines effectuant un travail désordonné, donc le travail d'optimisation utile est la gestion des ressources : CPU, mémoire, disque, réseau, exécuteurs, plugins, rétention et conception des agents.

Ce guide se concentre sur l'optimisation pratique des performances de Jenkins pour les systèmes CI/CD réels. L'objectif n'est pas d'extraire chaque dernier point de benchmark de Jenkins. L'objectif est de maintenir les builds prévisibles, de garder le contrôleur en bonne santé et de rendre évident d'où viendra le prochain goulot d'étranglement.

Comprendre la Consommation des Ressources de Jenkins

Jenkins lui-même, ainsi que les tâches qu'il exécute via les agents, consomme trois ressources principales : les cycles CPU, la RAM et les E/S disque. Les goulots d'étranglement de performance surviennent souvent lorsque ces ressources sont sous-dimensionnées, sur-réservées ou mal configurées.

1. Allocation et Gestion du CPU

La disponibilité du CPU impacte directement la rapidité avec laquelle Jenkins peut planifier les tâches et la vitesse à laquelle les builds individuels s'exécutent. Une mauvaise gestion ici entraîne souvent des charges moyennes élevées et des retards notables.

Allocation CPU Maître vs Agent

Il est de pratique courante de déléguer le travail lourd (compilation, tests) aux agents Jenkins plutôt qu'au contrôleur Jenkins. Les documentations plus anciennes peuvent appeler cela "maître" et "esclave" ; les termes Jenkins actuels sont contrôleur et agent. Le contrôleur doit être réservé à la coordination, au service de l'interface utilisateur et aux interactions API.

Nœud Contrôleur : Allouez suffisamment de CPU pour gérer les requêtes simultanées, mais maintenez une charge de travail faible. Une installation petite ou modérée peut fonctionner sur quelques cœurs, mais les contrôleurs occupés ont besoin de mesure plutôt que d'une règle fixe.
Nœuds Agents : Ceux-ci doivent recevoir la majorité de la puissance CPU, dimensionnée en fonction de la charge de build simultanée anticipée.

Limitation des Emplacements d'Exécuteurs

L'un des moyens les plus efficaces de contrôler la contention CPU est de limiter le nombre de builds simultanés.

Sur le Nœud Maître :

Configurez le nombre d'exécuteurs directement sur la page de configuration principale de Jenkins ou via les paramètres de configuration du nœud pour les Agents.

Si vous avez un agent avec $N$ cœurs CPU, définir le nombre d'exécuteurs à légèrement moins que $N$ (par exemple, $N-1$ ou $N/2$ si les builds sont extrêmement intensifs en CPU) empêche le système d'être complètement saturé, permettant au système d'exploitation et aux tâches d'arrière-plan de Jenkins de respirer.

Exemple de Configuration pour un Agent :

Lors de la configuration d'un nouvel agent (Nœud), recherchez le champ 'Nombre d'exécuteurs'. Définissez-le de manière conservatrice en fonction des capacités matérielles.

# Extrait de Configuration d'Agent (Conceptuel)
NUM_EXECUTORS = 4  # Pour une machine à 8 cœurs exécutant des builds lourds

2. Gestion de la Mémoire (RAM)

Une RAM insuffisante entraîne un swap excessif (pagination des données sur le disque), ce qui dégrade sévèrement les performances. Jenkins dépend fortement de la Machine Virtuelle Java (JVM), ce qui rend le dimensionnement du tas critique.

Réglage de la Taille du Tas JVM du Contrôleur Jenkins

La taille du tas JVM du contrôleur est l'un des paramètres de mémoire les plus importants.

Ceci est généralement configuré en modifiant la variable d'environnement JENKINS_JAVA_OPTIONS avant le démarrage de Jenkins (par exemple, dans /etc/default/jenkins ou les fichiers de service systemd).

Meilleure Pratique : Laissez une mémoire significative pour le système d'exploitation, le cache du système de fichiers, les agents de surveillance et tous les processus secondaires. De nombreuses équipes maintiennent le tas en dessous de la majeure partie de la RAM système plutôt que de donner tout à Java.

Exemple d'Options JVM :

Si le serveur dispose de 16 Go de RAM, un point de départ raisonnable pourrait être un tas de 8 Go, puis ajustez en fonction des journaux de garbage collection et de l'utilisation réelle :

export JENKINS_JAVA_OPTIONS="-Xms8192m -Xmx10240m -Djava.awt.headless=true -XX:MaxMetaspaceSize=512m"

-Xms : Taille initiale du tas.
-Xmx : Taille maximale du tas. De nombreuses configurations de production définissent cela égal à -Xms pour éviter le redimensionnement du tas pendant l'exécution.

Surveillance et Garbage Collection (GC)

Une utilisation élevée de la mémoire entraîne souvent des pauses de Garbage Collection fréquentes et longues. Surveillez les journaux GC (activés via des flags JVM supplémentaires) pour identifier si le tas est correctement dimensionné ou s'il y a des fuites mémoire dans les plugins ou les processus de build.

3. Optimisation des E/S Disque

Les performances du disque sont souvent le tueur silencieux de la vitesse CI/CD, en particulier lors de la manipulation de gros artefacts, de caches de dépendances ou de checkouts/suppressions fréquents.

Volumes Séparés pour l'Espace de Travail et les Journaux

Si possible, séparez les zones d'activité d'écriture élevée de l'installation principale de Jenkins.

Jenkins Home ($JENKINS_HOME) : Cela abrite la configuration, les enregistrements de build et les journaux système. Il nécessite un stockage fiable et de vitesse moyenne (SSD recommandé).
Espaces de Travail de Build : Ces répertoires subissent des opérations massives et fréquentes de lecture/écriture/suppression. Idéalement, placez le répertoire principal où résident les espaces de travail sur le stockage le plus rapide disponible (NVMe/SSD).

Astuce : Assurez-vous que le système de fichiers utilisé pour les espaces de travail (par exemple, ext4, XFS) est bien entretenu et dispose de suffisamment d'inodes.

Utilisation de Stratégies de Mise en Cache des Builds

Minimiser l'activité disque grâce à une mise en cache intelligente est un gain de performance majeur :

Mise en Cache des Dépendances : Configurez Maven, Gradle, npm ou pip pour utiliser des caches partagés persistants sur les nœuds Agents plutôt que de retélécharger les dépendances pour chaque build.
Nettoyage de l'Espace de Travail : Nettoyez agressivement les espaces de travail obsolètes. Bien que conserver les espaces de travail puisse aider au débogage, ils consomment de l'espace disque et ralentissent les opérations disque s'ils sont trop nombreux.
- Utilisez des étapes de pipeline comme cleanWs() ou configurez les paramètres de l'agent pour supprimer automatiquement les espaces de travail après une période de temps spécifique.

Systèmes de Fichiers Réseau (NFS/SMB)

Avertissement : Évitez d'utiliser des systèmes de fichiers réseau (NFS ou SMB) pour les volumes à écriture élevée comme les espaces de travail de build, sauf si le lien réseau et le tableau de stockage sont extrêmement haut débit et faible latence. La latence réseau introduit une surcharge significative pour les tâches liées aux E/S.

Techniques Avancées de Performance

Au-delà de l'allocation de ressources de base, plusieurs points de réglage architecturaux et opérationnels peuvent apporter des avantages significatifs.

Optimisation et Mise à l'Échelle des Exécuteurs

Pour les environnements avec une charge imprévisible, la mise à l'échelle dynamique est essentielle.

Agents Natifs Cloud (Agents Éphémères)

Utilisez des Agents Jenkins provisionnés à la demande (par exemple, via les plugins Kubernetes, Docker ou EC2). Ces agents sont démarrés exactement quand nécessaire et terminés après. Cela garantit que les ressources ne sont consommées que pendant les builds actifs, évitant les frais généraux gaspillés des agents inactifs fonctionnant en permanence.

Gestion des Plugins

Les plugins peuvent contribuer de manière significative à l'empreinte mémoire et à la charge de traitement du contrôleur.

Audit des Plugins : Examinez régulièrement les plugins installés. Supprimez ceux qui sont inutilisés ou obsolètes, car ils consomment de la mémoire et peuvent introduire des régressions de performance.
Délégation du Travail : Dans la mesure du possible, configurez les plugins pour effectuer leur travail lourd sur les agents plutôt que sur le contrôleur. Par exemple, les outils qui génèrent des rapports ou effectuent une indexation doivent s'exécuter sur un agent.

Utilisation d'Outils de Surveillance des Performances

Le réglage réactif est insuffisant ; la surveillance proactive est essentielle. Intégrez des outils de surveillance pour suivre les métriques clés :

Niveau Système : Utilisation du CPU, utilisation de la RAM, temps d'attente des E/S disque.
Niveau Jenkins : Percentiles de latence des builds (P95, P99), temps de file d'attente, utilisation des exécuteurs.

Des outils comme Prometheus/Grafana ou les fonctionnalités de surveillance intégrées de Jenkins (comme le plugin Metrics) fournissent la visibilité nécessaire pour justifier les ajustements de ressources.

Résumé des Meilleures Pratiques

Ressource	Meilleure Pratique	Astuce Actionnable
CPU	Déléguez la charge lourde aux Agents.	Définissez les exécuteurs de l'Agent légèrement en dessous du nombre de cœurs pour la sécurité.
Mémoire (Maître)	Réglez la taille du tas JVM (`-Xmx`).	Allouez 50 à 75 % de la RAM physique, définissez Xms=Xmx.
E/S Disque	Utilisez un stockage local rapide (SSD/NVMe) pour les espaces de travail.	Évitez d'utiliser NFS/SMB pour les répertoires de build à écriture élevée.
Charge de Travail	Implémentez une mise en cache agressive.	Configurez les gestionnaires de dépendances (Maven/npm) pour utiliser des caches partagés persistants sur les Agents.
Architecture	Utilisez des agents dynamiques et éphémères.	Tirez parti des plugins Kubernetes ou Docker pour dimensionner les ressources en fonction de la profondeur de la file d'attente.

Commencez par le Contrôleur : Gardez-le Ennuyeux

Le contrôleur doit être ennuyeux. C'est un compliment. Un contrôleur ennuyeux planifie les builds, stocke la configuration des tâches, sert les pages, parle aux agents et écrit les métadonnées. Il n'exécute pas de suites de tests, ne construit pas de conteneurs, ne scanne pas d'énormes arbres de dépendances et ne publie pas de rapports de plusieurs gigaoctets. Lorsque le contrôleur devient juste une autre machine de build, chaque équipe partage le rayon d'explosion.

Définissez le nombre d'exécuteurs du contrôleur à zéro, sauf si vous avez une petite installation sur une seule machine ou une exception très délibérée. Ce seul changement empêche les charges de travail accidentelles d'atterrir sur le nœud le plus important du système. Si une tâche doit vraiment s'y exécuter, demandez pourquoi. Souvent, la réponse est "parce qu'un outil y est installé", et la meilleure solution est de créer une image d'agent avec cet outil.

Surveillez le CPU du contrôleur séparément du CPU de l'agent. Un contrôleur avec un CPU élevé alors qu'aucun build n'est en cours peut être confronté à une activité de plugin, une indexation de branche, un rendu de journal, des recherches dans le domaine de sécurité ou trop d'historique de tâches. Un contrôleur avec un CPU élevé pendant les heures de pointe de build peut planifier trop de pipelines, sérialiser de gros journaux ou traiter des rapports qui devraient être gérés ailleurs.

Le réglage de la mémoire suit le même modèle. Un tas plus grand peut réduire la pression du garbage collection, mais il peut aussi cacher une fuite de plugin pendant un certain temps et aggraver les pauses éventuelles. Activez la journalisation GC, surveillez l'utilisation de l'ancienne génération après les collections complètes et comparez le comportement de la mémoire avant et après les mises à niveau de plugins. Si l'utilisation du tas augmente toute la journée et ne revient jamais, n'appelez pas cela une croissance normale avant d'avoir éliminé les fuites ou les tâches incontrôlées.

Réglez les Exécuteurs en Fonction de la Charge de Travail, Pas Seulement du Nombre de Cœurs

Le raccourci courant "un exécuteur par cœur" n'est qu'une estimation de départ. Un build qui passe la plupart de son temps à attendre des téléchargements réseau peut tolérer plus de concurrence qu'un build qui compile du C++ ou exécute des tests de navigateur. Une tâche qui crée des milliers de petits fichiers peut saturer le disque bien avant que le CPU ne semble occupé. Une tâche qui exécute Docker-in-Docker peut rencontrer des limites de pilote de stockage ou des limites réseau de manière surprenante.

Pour les builds intensifs en CPU, commencez de manière conservatrice. Sur un agent à 8 cœurs, quatre exécuteurs peuvent produire de meilleurs temps de build moyens que huit. Pour les builds intensifs en E/S, mesurez l'attente disque et la latence du système de fichiers tout en augmentant lentement la concurrence. Pour les builds intensifs en mémoire, suivez la mémoire résidente par build et laissez de la place pour le cache du système d'exploitation. L'activité de swap sur un agent Jenkins est généralement le signe que le nombre d'exécuteurs est trop élevé ou que la tâche a besoin d'une machine plus grande.

Les labels font partie de la gestion des ressources. N'envoyez pas tout à un label linux générique si certaines tâches ont besoin de Docker, d'autres de mémoire élevée et d'autres d'un compilateur sous licence. Créez des labels qui décrivent les profils de ressources. Examinez ensuite le temps de file d'attente par label. Cela vous indique si vous avez besoin de plus d'agents linux-docker, de plus d'agents à mémoire élevée ou de moins de tâches épinglées à un environnement rare.

Le Disque Est Souvent le Goulot d'Étranglement Caché

Jenkins crée, lit et supprime beaucoup de fichiers. Les checkouts de code source, les caches de dépendances, les rapports de test, les fichiers de couverture, les artefacts de build, les journaux archivés et les fichiers temporaires touchent tous le disque. Lorsque le disque est lent, les builds semblent aléatoirement lents. Lorsque le disque se remplit, les builds échouent d'une manière qui fait perdre beaucoup de temps humain.

Placez les espaces de travail occupés sur un stockage local rapide lorsque cela est possible. Utilisez des volumes séparés pour $JENKINS_HOME, les espaces de travail et les grands caches si votre infrastructure le permet. Cette séparation facilite la croissance des parties bruyantes sans risquer la configuration du contrôleur et les métadonnées de build. Cela rend également le dépannage plus clair : si les E/S de l'espace de travail sont saturées, vous savez où chercher.

Soyez prudent avec les systèmes de fichiers réseau. NFS et SMB peuvent convenir pour certains actifs partagés, mais ils sont souvent pénibles pour les espaces de travail actifs avec de nombreux petits fichiers. Une installation JavaScript, un build Maven ou une suite de tests qui crée des milliers de fichiers temporaires peut transformer la latence réseau en minutes de temps perdu. Si vous devez utiliser un stockage réseau, comparez votre charge de travail réelle au lieu de vous fier aux chiffres de débit bruts.

Les paramètres de rétention sont importants. Conserver chaque artefact pour toujours est coûteux. Ne conserver aucun historique est pénible lors de la révision d'incidents. Une configuration pratique conserve suffisamment de builds pour le débogage et la conformité, publie les artefacts à long terme dans un référentiel d'artefacts et expire automatiquement les anciens journaux et espaces de travail. La fenêtre de rétention exacte dépend de l'équipe, mais la décision doit être explicite.

Mise en Cache Sans Créer de Nouveaux Problèmes

La mise en cache est l'un des moyens les plus rapides d'améliorer les performances de Jenkins. C'est aussi l'un des moyens les plus simples de créer des builds étranges si le cache n'est pas conçu avec soin.

Pour les gestionnaires de dépendances, préférez un véritable référentiel ou proxy de paquets pour les téléchargements partagés : Nexus, Artifactory, un registre npm privé, un proxy Maven ou un service de cache spécifique au langage. Utilisez ensuite des caches locaux par agent pour éviter les téléchargements répétés. Cela vous donne de la vitesse sans laisser chaque tâche écrire dans un répertoire partagé fragile.

Pour les builds Docker, ordonnez les instructions Dockerfile afin que les couches de dépendances restent stables. Copiez d'abord les fichiers manifestes, installez les dépendances, puis copiez le reste du code source. Utilisez les montages de cache BuildKit là où ils conviennent. Si les agents sont éphémères, envisagez des images de base pré-construites qui contiennent déjà les chaînes d'outils courantes. Tirer une image géante à chaque build peut annuler l'avantage des agents dynamiques.

Pour les caches de test, soyez honnête quant à l'exactitude. Les caches de compilateur et les caches de dépendances sont généralement sûrs lorsqu'ils sont bien indexés. La réutilisation des résultats de test est plus dangereuse à moins que le système de build ne comprenne précisément les entrées. Un build rapide et incorrect est pire qu'un build lent et correct.

Surveillance Qui Aide Vraiment

Un tableau de bord Jenkins devrait répondre à quelques questions simples. Les tâches attendent-elles parce qu'il n'y a pas assez d'exécuteurs compatibles ? Les agents échouent-ils à se connecter ou à démarrer ? Le contrôleur passe-t-il trop de temps dans le garbage collection ? Le disque se remplit-il plus vite que le nettoyage ne supprime les données ? Quelques tâches consomment-elles la plupart des minutes d'exécuteur ?

Suivez le temps de file d'attente par label, l'utilisation des exécuteurs par agent, la durée de build par tâche, le tas du contrôleur, le temps de pause GC, l'utilisation du disque, l'attente des E/S disque, les échecs de lancement d'agent et les déconnexions de communication à distance. Les percentiles sont plus utiles que les moyennes. Si le build médian est correct mais que les dix pour cent les plus lents sont terribles, les utilisateurs percevront toujours Jenkins comme peu fiable.

Conservez un court journal des modifications pour le réglage. Notez quand vous avez modifié la taille du tas, le nombre d'exécuteurs, les versions de plugins, les politiques de rétention, les images d'agent ou les chemins de cache. Sans cet historique, vous finirez par regarder un graphique et vous demander ce qui s'est passé mardi dernier.

Une Boucle de Réglage Sensée

Choisissez un goulot d'étranglement. Changez une chose significative. Mesurez suffisamment longtemps pour inclure le trafic de pointe normal. Conservez le changement s'il a aidé et n'a pas créé un nouveau mode de défaillance. Revenez en arrière si l'amélioration n'apparaît qu'en théorie.

Par exemple, si une tâche Maven passe six minutes à résoudre les dépendances, ajoutez un proxy de référentiel et un cache local d'agent. Si le temps de file d'attente reste élevé après cela, ajoutez des agents pour le label concerné. Si l'interface du contrôleur est toujours lente lorsque les builds sont calmes, examinez les plugins, le nombre de tâches, l'indexation des branches et le comportement du tas. Chaque étape réduit le problème au lieu de transformer Jenkins en un tas de suppositions.

En abordant systématiquement le CPU, la mémoire, le disque, la mise en cache et la capacité des agents, vous rendez Jenkins moins dramatique. C'est le meilleur type d'amélioration CI : les développeurs arrêtent de penser à l'outil et se remettent à livrer du code.