À 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 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
Sur GitHub Enterprise Server la version 3.13 et les versions antérieures, les fichiers de données Governor se trouvent sous /data/user/gitmon/ et utilisent le modèle gitmon.<timestamp>.dbde nommage .
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, collectez ces informations :
- 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) ». - 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 un résumé large, puis attribuez une charge d’attribut à 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-objectsle temps processeur est consommé le plus. Lepack-objectsprogramme assemble les données envoyées aux clients pendant les clones et les extractions ; un nombre élevé place une pression importante sur le processeur et la mémoire sur 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 -
Recherchez une concurrence élevée, 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 le clone principal et extraire le trafic
Le upload-pack programme gère les données servies aux clients pendant les clones et les extractions. 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.
-
Compter les opérations de clonage et d’extraction par dépôt :
ghe-governor aggregate repo count -P upload-pack -
Identifiez les utilisateurs exécutant des clones et récupère et comptent 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 avec un nombre élevé indique souvent une flotte d’exécuteurs 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 -
Recherchez le clone de pointe et récupérez la concurrence par référentiel. 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 -
Recherchez le plus grand clone individuel ou les opérations d’extraction (non regroupées) :
ghe-governor top uploaded -P upload-pack -n 50
Identifier le trafic lourd par envoi (push)
Les programmes et spokes-receive-pack les receive-pack programmes gèrent les données reçues des clients pendant les envois push. 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 envoyant les données push les plus :
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 ou ghe-governor aggregate une ghe-governor top commande pour concentrer la requête sur une fenêtre de temps, 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 de 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 |
| Minutes relatives | -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 la sortie aux enregistrements N. 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 et COUNT les KEY colonnes. 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, que les appels Git ont pris |
MAX RT | Temps d’exécution, en secondes, de l’appel le plus long en cours d’exécution, par hôte |
MAXPL / AVGPL | Parallélisme maximal et moyen : nombre d’appels Git en attente à la fois |
CPU/SEC | Secondes de temps processeur utilisé par Git par seconde de temps d’horloge murale. Divisez par le nombre de cœurs d’UC et multipliez par 100 pour obtenir le pourcentage d’UC spécifique à Git. Cette valeur ne peut pas dépasser le nombre de cœurs d’UC. |
UPL | Données chargées sur le serveur sur les clients, telles que lors des extractions et des clones |
RECV | Données reçues par le serveur des clients, telles que pendant les envois (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 mappe les modèles de sortie de Governor courants à leurs causes probables.
| Pattern | Cause la plus probable |
|---|---|
Nombre élevé upload-pack d’adresses IP d’un petit ensemble 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 |
Grand uploaded_kb par référentiel combiné à élevé avg_uploaded par utilisateur | Clones complets répétés ; les clients ne réutilisent pas les caisses locales ou n’utilisent pas de clones peu profonds ou partiels |
Élevé received_kb pour un référentiel ou une organisation | Charge de travail intensive par envoi (push) ; peut impliquer des fichiers binaires volumineux ou des validations fréquentes dans un monorepo |
Processeur élevé pack-objects avec des nombres d’opérations modérés | Emballage d’objets coûteux ; le référentiel peut tirer parti d’une exécution de maintenance ou d’une utilisation côté client des clones 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 nouveaux clones par des flux de travail automatisés
git fetch. 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 les données transférées et le travailpack-objectsdoit faire. - 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 flottes d’exécuteurs volumineuses qui clonent les mêmes référentiels à plusieurs reprises, un proxy d’extraction ou un miroir local peut absorber le trafic d’extraction et réduire la charge sur votre instance.
- Travaux planifiés par stagger. Décalage des flux de travail CI/CD déclenchés selon une planification afin que tous les exécuteurs ne démarrent pas en même temps, ce qui réduit la taille des rafales de clone simultanées.
- 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 et incluez Support GitHub Enterprise un groupe de support si l’un des éléments suivants s’applique.
- Les performances restent détériorées après la réduction de la pression du clone ou des travaux planifiés.
- 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 persistantes
max_parallelismindiquant que l’instance est à une capacité proche ou proche, et que les modifications de charge de travail seules sont peu susceptibles de 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.