À propos du gouverneur
Governor est un moniteur intégré pour l’activité Git sur votre instance. Utilisez la ghe-governor commande pour voir quels référentiels, utilisateurs, adresses IP et opérations Git créent une charge.
Utilisez ces données lorsque l’utilisation du processeur, de la mémoire ou du disque augmente et que vous devez vérifier si le trafic Git est la cause. Pour obtenir la syntaxe de commande et les sous-commandes, consultez Utilitaires de ligne de commande.
Governor enregistre uniquement les opérations Git. Il n’inclut pas l’API ou le trafic web. Pour inspecter les opérations en cours d’exécution, consultez l’utilitaire ghe-btop dans Utilitaires de ligne de commande.
À propos des fichiers de données de Governor
Governor stocke ses données dans les fichiers sous /data/user/governor/. Chaque fichier contient une heure de données et est conservé pendant deux semaines. Les noms de fichiers contiennent des horodatages Unix qui indiquent la période couvre chaque fichier.
Remarque
Dans GitHub Enterprise Server, la version 3.13 et les versions antérieures, les fichiers de données de Governor sont situés dans /data/user/gitmon/ et suivent le modèle de nommage gitmon.<timestamp>.db.
Pour confirmer la plage de données actuellement conservées sur le disque, convertissez les horodatages dans les noms de fichiers les plus anciens et les plus récents en dates lisibles par l’homme.
for epoch in $(sudo ls /data/user/governor/ 2>/dev/null | grep '^governor\.' | sort | sed -n '1p;$p' | cut -f2 -d.); do echo "${epoch} = $(date -d @${epoch})"; done
La sortie affiche l’heure de début des fichiers de données les plus anciens et les plus récents.
1551186000 = Tue Feb 26 13:00:00 UTC 2019
1552392000 = Tue Mar 12 12:00:00 UTC 2019
Avant de commencer
Avant d’exécuter des requêtes Governor, rassemblez les informations suivantes :
- Accès SSH à l’appliance. Vous devez accéder à l’interpréteur de commandes d’administration pour exécuter
ghe-governor. Consultez « Accès à l’interpréteur de commandes d’administration (SSH) ». - Quel nœud interroger. Pour les déploiements autonomes ou à haute disponibilité, démarrez sur le nœud principal. Pour les clusters, exécutez des requêtes sur chaque
git-servernœud, car aucun nœud unique ne contient tout le trafic Git. - Fenêtre d’impact. Notez les heures de début et de fin de la dégradation signalée pour que vous puissiez étendre les requêtes avec
-tet-u. - Noms de référentiel ou d’organisation, si les utilisateurs ont signalé des problèmes avec des référentiels ou des organisations spécifiques.
Identifier si Git contribue au chargement
Commencez par une vue d’ensemble, puis attribuez la charge à des référentiels ou programmes spécifiques.
-
Résumez toutes les activités Git récentes sur votre instance :
ghe-governor health -
Recherchez les référentiels avec le temps de réponse moyen le plus lent :
ghe-governor aggregate repo avg_rt -
Recherchez les référentiels avec la plus longue opération unique :
ghe-governor aggregate repo max_rt -
Recherchez les opérations individuelles les plus lentes (non regroupées) :
ghe-governor top rt -n 50 -
Recherchez les référentiels qui consomment le plus de temps processeur :
ghe-governor aggregate repo cpu -
Pour un référentiel qui se distingue, recherchez quel sous-programme Git est responsable de son utilisation du processeur :
ghe-governor aggregate program cpu -r OWNER/REPOSITORY -
Recherchez les référentiels où
pack-objectsa consommé le plus de temps processeur. Le programmepack-objectsassemble les données envoyées aux clients pendant les clones et les récupérations ; un nombre important sollicite fortement le processeur et la mémoire de l’appliance :ghe-governor aggregate repo cpu -P pack-objects -
Recherchez les opérations individuelles qui utilisaient le plus de temps processeur (pas regroupé) :
ghe-governor top cpu -n 50 -
Recherchez les référentiels qui pilotent le plus d’écritures de disque pendant un intervalle de temps spécifique :
ghe-governor aggregate repo disk_write_kb -t START-TIME -u END-TIME -
Vérifiez s’il existe une forte concurrence, ce qui indique que de nombreuses opérations Git s’exécutent simultanément :
ghe-governor aggregate repo max_parallelism
Si les résultats pointent vers un référentiel ou un programme spécifique, passez à la section appropriée ci-dessous.
Identifier les principaux trafics de clonage et de récupération
Le upload-pack programme gère les données servies aux clients lors des clonages et des récupérations. Utilisez ces requêtes pour rechercher les référentiels, les utilisateurs et les adresses IP qui pilotent la plus grande activité de clonage et de récupération.
-
Nombre d’opérations de clonage et de récupération (fetch) par dépôt :
ghe-governor aggregate repo count -P upload-pack -
Identifiez les utilisateurs effectuant des clones et des fetchs, et comptez leurs opérations :
ghe-governor aggregate user_id count -P upload-pack -
Identifiez les adresses IP générant les requêtes de clonage et de récupération les plus fréquentes. Un petit ensemble d’adresses IP présentant un nombre élevé indique souvent une flotte de runners CI :
ghe-governor aggregate ip count -P upload-pack -
Mesurez le volume total de données servies par référentiel :
ghe-governor aggregate repo uploaded_kb -P upload-pack -
Mesurez le volume moyen de données chargées par utilisateur :
ghe-governor aggregate user_id avg_uploaded -P upload-pack -
Trouvez le nombre maximal d’opérations de clonage et de récupération simultanées par dépôt. La
MAXPLcolonne affiche le nombre maximal d’opérations simultanées enregistrées pour chaque référentiel. Une valeur élevée pour un petit nombre de référentiels suggère un troupeau tonnerre :ghe-governor aggregate repo max_parallelism -P upload-pack -
Trouvez les opérations individuelles de clonage ou de récupération les plus volumineuses (non regroupées) :
ghe-governor top uploaded -P upload-pack -n 50
Identifier le trafic dominé par les notifications push
Les programmes receive-pack et spokes-receive-pack gèrent les données reçues de clients lors des pushs. Utilisez ces requêtes pour rechercher les référentiels, les utilisateurs et les adresses IP qui génèrent la plus grande activité Push.
-
Compter les opérations push par dépôt :
ghe-governor aggregate repo count -P receive-pack -P spokes-receive-pack -
Identifiez les utilisateurs qui poussent vers une organisation et comptent leurs opérations push :
ghe-governor aggregate user_id count -o ORGANIZATION -P receive-pack -P spokes-receive-pack -
Mesurez le volume total de données reçues par dépôt :
ghe-governor aggregate repo received_kb -P receive-pack -P spokes-receive-pack -
Identifiez les adresses IP qui envoient le plus de données de notification push :
ghe-governor aggregate ip received_kb -P receive-pack -P spokes-receive-pack -
Recherchez les opérations push individuelles les plus importantes (pas regroupées) :
ghe-governor top received -P receive-pack -P spokes-receive-pack -n 50
Affiner l’analyse
Vous pouvez ajouter n’importe quelle combinaison des options suivantes à une commande ghe-governor top ou ghe-governor aggregate pour cibler la requête sur une période donnée, un référentiel, un propriétaire ou un programme spécifique.
Filtres de temps
| Option | Description |
|---|---|
-t <timespec> | Envisagez uniquement les opérations depuis une heure de début donnée. La valeur par défaut est il y a 48 heures. |
-u <timespec> | Envisagez uniquement les opérations jusqu’à une heure de fin donnée. La valeur par défaut est l’heure actuelle. |
Les formats suivants sont acceptés pour <timespec>.
| Format | Example | Meaning |
|---|---|---|
| Horodatage Unix | -t 1371614483 | Secondes depuis le 1er janvier 1970 |
| horodatage Java | -t 1371614483637 | Millisecondes depuis le 1er janvier 1970 |
| Jours relatifs | -t 1d | Le dernier jour |
| Heures relatives | -t 2h | Les deux dernières heures |
| Décalage en minutes | -t 20m | Les vingt dernières minutes |
Filtres d’étendue
| Option | Description |
|---|---|
-r <owner>/ | Envisagez uniquement les opérations correspondant à un propriétaire et un référentiel donnés. Spécifiez cette option plusieurs fois pour qu’elle corresponde à plusieurs référentiels. |
-o <owner> | Envisagez uniquement les opérations correspondant à un propriétaire donné, comme un utilisateur ou une organisation. Spécifiez cette option plusieurs fois pour correspondre à plusieurs propriétaires. |
-P <program> | Considérez uniquement les opérations qui ont exécuté un sous-programme Git donné, tel que upload-pack, , receive-pack``rev-list, ou pack-objects. Spécifiez cette option plusieurs fois pour qu’elle corresponde à plusieurs programmes. |
-I <address> | Envisagez uniquement les opérations à partir d’une adresse IP spécifique. Spécifiez cette option plusieurs fois pour qu’elle corresponde à plusieurs adresses. |
Options de sortie
| Option | Description |
|---|---|
-j | Définissez le format de sortie sur JSON au lieu d’une table ASCII. |
-n <N> | Limitez le résultat à N enregistrements. La valeur par défaut est 20 pour les requêtes d’agrégation et 200 pour les requêtes principales. |
--count-only | Afficher uniquement les colonnes KEY et COUNT. S’applique uniquement aux requêtes d’agrégation. |
Interprétation des colonnes de résultats
Les abréviations suivantes apparaissent dans ghe-governor les tableaux de résultats.
| Column | Meaning |
|---|---|
AVG RT | Temps moyen, en secondes, des invocations de Git |
MAX RT | Temps d’exécution, en secondes, de l’invocation la plus longue, par hôte |
MAXPL / AVGPL | Parallélisme maximal et moyen : nombre d’invocations de Git en cours simultanément |
CPU/SEC | Secondes de temps processeur utilisé par Git par seconde de temps d’horloge murale. Divisez par le nombre de cœurs de processeur et multipliez par 100 pour obtenir le pourcentage d’utilisation du processeur propre à Git. Cette valeur ne peut pas dépasser le nombre de cœurs du processeur. |
UPL | Données que le serveur téléverse vers les clients, par exemple lors des récupérations et des clonages |
RECV | Données reçues par le serveur en provenance des clients, par exemple lors d’opérations de push |
Les READcolonnes et les WRITE``UPL``RECV colonnes sont signalées en gigaoctets (Go) et le taux correspondant est signalé en mégaoctets par seconde (Mo/s).
Interpréter les modèles courants
Le tableau suivant associe les types de sortie courants de Governor à leurs causes probables.
| Pattern | Cause la plus probable |
|---|---|
Nombre élevé upload-pack provenant d’un petit nombre d’adresses IP | Une flotte d’exécuteurs CI clone à plusieurs reprises un ou plusieurs référentiels au lieu de réutiliser les caisses locales |
Élevé max_parallelism pour un petit nombre de référentiels | Troupeau tonneur : de nombreux coureurs déclenchant des clones simultanés en même temps, souvent parce que les travaux planifiés démarrent simultanément |
Nombre élevé de uploaded_kb par dépôt, combiné à un nombre élevé de avg_uploaded par utilisateur | Clones complets répétés ; les clients ne réutilisent pas les copies de travail locales ou n’utilisent pas de clones superficiels ou partiels |
Niveau élevé received_kb pour un dépôt ou une organisation | Charge de travail à forte fréquence de push ; peut impliquer des fichiers binaires volumineux ou des commits fréquents sur un monorepo |
Processeur élevé pack-objects avec des nombres d’opérations modérés | Compression d’objets coûteuse ; le dépôt pourrait bénéficier d’une opération de maintenance ou de l’utilisation côté client de clonages partiels avec --filter |
Élevé avg_rt ou max_rt pour un référentiel | Opérations lentes ; souvent causée par des exécutions volumineuses pack-objects , une concurrence élevée ou une contention de ressources à partir d’une autre charge de travail |
Actions recommandées pour la réduction de charge Git
Si les données Governor indiquent qu’un référentiel, un utilisateur ou une flotte d’exécuteurs génère une charge excessive, les actions suivantes peuvent réduire l’impact.
- Réutiliser les caisses locales. Remplacez les clones fraîchement créés par
git fetchdans les flux de travail automatisés. Cela évite de transférer le graphique d’objet complet sur chaque exécution. - Utilisez des clones peu profonds. Pour les flux de travail qui ne nécessitent pas d’historique de validation complet, passez
--depthà la commande clone, par exemplegit clone --depth 1. Cela réduit à la fois les données transférées et le travail quepack-objectsdoit effectuer. - Utilisez des clones partiels. Pour les référentiels avec des objets binaires volumineux ou de nombreux fichiers non nécessaires dans un flux de travail donné, utilisez
--filterpour demander uniquement les objets requis par le flux de travail, par exemplegit clone --filter=blob:none. - Ajoutez un proxy local de mise en miroir ou de mise en cache. Pour les grandes flottes d’exécuteurs qui clonent à plusieurs reprises les mêmes référentiels, un proxy relais ou un miroir local peut absorber le trafic de récupération et réduire la charge sur votre instance.
- Décalez les tâches planifiées. Décalez les workflows CI/CD déclenchés à intervalles planifiés afin que tous les runners ne démarrent pas en même temps, ce qui réduit l’ampleur des pics simultanés de clonage.
- Réduisez le parallélisme du flux de travail. Les flux de travail qui clonent plusieurs référentiels en parallèle peuvent être reconfigurés pour limiter la concurrence et répartir la charge au fil du temps.
Quand contacter le support technique GitHub
Contactez Support GitHub Enterprise et incluez une archive de support si l’un des cas suivants s’applique.
- Les performances restent dégradées après avoir réduit la charge liée aux clones ou échelonné les tâches planifiées.
- Votre instance sert des erreurs Git généralisées ou des échecs de connexion qui ne sont pas expliqués par la charge de travail du client.
- Governor affiche des valeurs
max_parallelismpersistantes indiquant que l’instance fonctionne à pleine capacité ou presque, et que les seules modifications de la charge de travail ne suffiront probablement pas à résoudre le problème. - Vous voyez un modèle clair dans la sortie du Gouverneur, mais vous ne savez pas comment l’interpréter ou quelle action entreprendre.
Pour plus d’informations sur la génération d’un bundle de support, consultez Fourniture de données au support GitHub.
Lectures complémentaires
Pour plus d’informations sur la surveillance des ressources système, consultez À propos des tableaux de bord de surveillance.