Cette version de GitHub Enterprise Server ne sera plus disponible le 2026-03-17. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Vérifiez la capacité du système avant la mise à niveau

Avant de mettre à niveau GitHub Enterprise Server, vous devez effectuer ces vérifications de capacité et suivre les étapes recommandées.

Dans cet article

La mise à niveau vers des versions plus récentes de GitHub Enterprise Server augmente généralement la consommation de ressources. Chaque version fonctionnelle ajoute de nouvelles fonctionnalités, certaines activées par défaut, d’autres en option, ce qui nécessite plus de puissance de traitement. Les habitudes d’utilisation des clients influent également sur la demande. Par exemple, les entreprises comptant des dizaines de milliers d’organisations peuvent constater une utilisation plus importante des ressources.

L’augmentation des ressources se traduit le plus souvent par une utilisation plus importante du processeur, un nombre plus élevé d’opérations d’E/S par seconde (IOPS), une consommation de mémoire plus importante ou des backlogs de la file d’attente Aqueduct plus importants. Pour vous préparer à ces changements, vérifiez la capacité disponible de votre système et appliquez les recommandations de correction avant de procéder à la mise à niveau. Effectuez ces vérifications pendant les périodes les plus chargées de la journée et de la semaine afin d’obtenir les résultats les plus précis.

Besoins en ressources

Avant de mettre à niveau votre instance, il est essentiel de vérifier que votre système répond aux exigences en matière de ressources :

  1. Utilisation du processeur inférieure à 70 %
  2. Utilisation de la mémoire inférieure à 70 %
  3. Disque non saturé
  4. File d’attente Unicorn inférieure à 200–300
  5. Backlog Aqueduct inférieur à 1–2 heures

Utilisation du processeur inférieure à 70 %

  1. Vérifiez l’utilisation du processeur. Dans Management Console, accédez à la page de surveillance (https://HOSTNAME.com:8443/setup/monitor) et affichez le graphique CPU.

    • Si l’utilisation est régulièrement inférieure à 70 %, passez à l’Utilisation de la mémoire.
    • Si l’utilisation est régulièrement supérieure à 70 %, le système ne répond pas aux critères de mise à niveau.

  2. Comparez l’utilisation avec la charge moyenne du processeur. La comparaison permet d’identifier une éventuelle saturation du disque.

    • Sur le graphique Load, cliquez sur court terme pour n’afficher que la courbe à court terme. Trouvez la valeur de charge maximale.

    • Sur le graphique CPU, cliquez sur inactivité pour n’afficher que la courbe d’inactivité. Notez la valeur d’inactivité au même horodatage.

    • Calculez l’utilisation :

      100 – idle

    • Calculez le pourcentage moyen de charge :

      (peak load value ÷ number of vCPUs) × 100

  3. Interprétez les résultats.

    Si le pourcentage moyen de charge du processeur est supérieur de plus de 50 % à l’utilisation, cela indique probablement une contention des ressources. Ne procédez pas à la mise à niveau tant que vous n’avez pas vérifié une éventuelle saturation du disque (consultez Disque non saturé).

Utilisation de la mémoire inférieure à 70 %

  1. Vérifiez l’utilisation de la mémoire. Dans Management Console, accédez à la page de surveillance (https://HOSTNAME.com:8443/setup/monitor) et affichez le graphique Memory.

  2. Interprétez les résultats.

    • Si l’utilisation de la mémoire est régulièrement inférieure à 70 %, passez à Disque non saturé.
    • Si l’utilisation de la mémoire est régulièrement supérieure à 70 %, le système ne répond pas aux critères de mise à niveau.

Disque non saturé

  1. Vérifiez les spécifications du fournisseur. Si votre fournisseur cloud ou matériel fournit des métriques d’utilisation du disque, utilisez-les pour confirmer si le disque est saturé.

    • Si les métriques ne sont pas disponibles, demandez les spécifications du disque à votre fournisseur, y compris le débit maximum et les IOPS maximum.
    • Comparez ces limites avec l’utilisation observée du disque. Si l’utilisation approche des valeurs maximales, le disque est saturé.

  2. Vérifiez les graphiques du disque dans la Management Console. Accédez à la page de surveillance (https://HOSTNAME.com:8443/setup/monitor).

    • Affichez les graphiques Disk Operations et Disk Traffic.

    • Comparez les valeurs de l’axe Y avec les spécifications de votre fournisseur (et non l’échelle maximale affichée sur le graphique).

    • Passez en revue les disques de données et les disques racine.

Ces graphiques sont disponibles dans les tableaux de bord par défaut de la page de surveillance.

  1. Interprétez les résultats. Si l’utilisation du disque approche les limites maximales définies par le fournisseur, le disque est saturé. Dans ce cas, le système ne répond pas aux critères requis pour la mise à niveau.

File d’attente Unicorn inférieure à 200–300

  1. Vérifiez le graphique des requêtes en attente. Dans Management Console, accédez à la page de surveillance (https://HOSTNAME.com:8443/setup/monitor) et affichez le graphique Queued Requests.

Ce graphique est disponible dans les tableaux de bord par défaut de la page de surveillance.

  1. Interprétez les résultats.

    • Si les requêtes en file d’attente sont constamment inférieures à 200, continuez avec Backlog Aqueduct inférieur à 1–2 heures.
    • Si les requêtes en file d’attente sont régulièrement à 200–300 ou plus, le système ne répond pas aux critères pour la mise à niveau.

  2. Facultatif : vérifiez l’utilisation des workers Unicorn. Depuis l’interpréteur de commandes administratif, exécutez :

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

    Consultez la dernière colonne de la sortie. Si tous les processus affichent > 90% utilization, davantage de workers Unicorn sont nécessaires.

Backlog Aqueduct inférieur à 1–2 heures

  1. Vérifiez la profondeur de la file d’attente Aqueduct. Dans Management Console, accédez à la page de surveillance (https://HOSTNAME.com:8443/setup/monitor) et affichez le graphique Aqueduct queue depth.

Ce graphique apparaît dans les tableaux de bord par défaut de la page de surveillance.

  1. Interprétez les résultats.

    • Si le backlog dure moins de 1–2 heures, vous remplissez cette exigence.
    • Si le backlog dure régulièrement plus de 1–2 heures, le système ne répond pas aux critères pour la mise à niveau.

  2. Surveillez la file d’attente index_high. Les déploiements importants peuvent entraîner des augmentations significatives de la profondeur de la file d’attente index_high, ce qui peut aggraver les backlogs. Accordez une attention particulière à cette file d’attente lors de la surveillance.

Si tous les critères (Processeur, mémoire, disque, file d’attente Unicorn, backlog Aqueduct) sont respectés, vous pouvez procéder à la mise à niveau vers la version fonctionnelle cible. Après la mise à niveau, attendez-vous à une augmentation supplémentaire de la consommation de ressources.

Si un critère n’est pas rempli, résolvez les problèmes sous-jacents avant de tenter la mise à niveau.

Mise à niveau du matériel et ajustement des workers

Si votre système ne répondait pas à une ou plusieurs exigences en matière de ressources, vous devrez augmenter la capacité avant la mise à niveau. Les sections suivantes expliquent comment ajouter des ressources matérielles et ajuster la configuration des workers pour résoudre les goulets d’étranglement courants.

  1. Processeur supérieur à 70 %
  2. Mémoire supérieure à 70 %
  3. Disque saturé
  4. File d’attente Unicorn supérieure à 200–300
  5. Backlog Aqueduct supérieur à 1–2 heures

Processeur supérieur à 70 %

Si l’utilisation du processeur est régulièrement supérieure à 70 % :

  • Augmentez les ressources du processeur. Ajoutez au moins 20 % de processeurs virtuels supplémentaires.
  • Compte pour les nouveaux workers. Allouez 1 processeur virtuel par worker. Par exemple, si vous ajoutez 5 workers Unicorn et 10 workers Resque, augmentez les processeurs virtuels d’au moins 15.

Mémoire supérieure à 70 %

Si l’utilisation de la mémoire est régulièrement supérieure à 70 % :

  • Augmentez la mémoire. Ajoutez de la RAM supplémentaire pour réduire l’utilisation moyenne en dessous de 70 %.
  • Compte pour les nouveaux workers. Allouez 1 Go de mémoire par worker. Par exemple, si vous ajoutez 5 workers Unicorn et 10 workers Resque, augmentez la mémoire d’au moins 15 Go.

Disque saturé

Si la vérification de la saturation du disque indique une saturation, passez à des disques offrant un débit plus élevé et un nombre maximal d’IOPS.

File d’attente Unicorn supérieure à 200–300

Si les requêtes Unicorn sont systématiquement en file d’attente au‑delà de 200–300, vous devrez peut-être ajouter davantage de workers Unicorn. Suivez ces étapes pour déterminer le nombre total de travailleurs cible et mettre à jour votre configuration.

1. Estimez le nombre de workers supplémentaires

Exécutez la commande suivante pendant les heures de pointe pour afficher l’utilisation par worker :

ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

Exemple de sortie :

git      3048972 3045762  0 Aug01 ?        00:07:47 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[00]: 20491 reqs,  10.8 req/s,   13ms avg,   85.2% util
git      3048979 3045762  0 Aug01 ?        00:07:53 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[01]: 20951 reqs,  12.5 req/s,   13ms avg,   80.3% util
git      3048985 3045762  0 Aug01 ?        00:08:04 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[02]: 21502 reqs,  10.5 req/s,   15ms avg,   76.5% util
git      3048992 3045762  0 Aug01 ?        00:07:45 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[03]: 20249 reqs,  14.2 req/s,   15ms avg,   86.9% util

La moyenne des requêtes par seconde est de 12 req/s.

À partir de cette sortie, calculez la moyenne des requêtes par seconde (req/s).

  • Dans l’exemple ci-dessus : 12 req/s.

  • L’objectif est de réduire les requêtes en file d’attente à ≤100.

  • Formule :

    (Queued requests – 100) ÷ avg req/s

  • Exemple : (280 – 100) ÷ 12 = 15 workers supplémentaires nécessaires.

    Conseil

    Si vous souhaitez confirmer vos résultats, vous pouvez nous contacter en visitant Support GitHub Enterprise, en téléversant un bundle et en demandant le nombre total de workers Unicorn cible.

2. Vérifiez la configuration actuelle

Assurez-vous que le nombre total de workers (Unicorn + Resque) ne dépasse pas le nombre de processeurs virtuels. Allouez au moins 1 processeur virtuel par worker.

Vérifiez le nombre actuel :

  • Workers Unicorn

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git | wc -l

    Ajoutez le nombre de nouveaux workers calculé à cette valeur pour obtenir le nombre total de workers cible.

  • Workers Resque

    ps -ef | grep aqueduct-1.1.0 | grep -v "grep aqueduct-1.1.0" | wc -l

3. Ajustez la configuration

Si la somme des workers Unicorn + Resque dépasse le nombre de processeurs virtuels, ajoutez davantage de processeurs virtuels avant de continuer.

Mettre à jour le nombre de workers Unicorn :

ghe-config app.github.github-workers <NUM-WORKERS>
ghe-config-apply

Remplacez par le nombre total de workers Unicorn cible.

Backlog Aqueduct supérieur à 1–2 heures

Si les jobs Aqueduct sont régulièrement backlogged pendant plus de 1–2 heures, ajoutez des workers resqued-low pour réduire le risque de files d’attente bloquées. Ce problème s’aggrave souvent après une mise à niveau.

1. Ajoutez des workers resqued-low

  • Augmentez le nombre de workers de 5–10. Tenez compte de la capacité du processeur : chaque worker nécessite au moins 1 processeur virtuel.
ghe-config app.github.resqued-low-workers <NUM-WORKERS>
ghe-config-apply

Remplacez par le nouveau nombre total de workers resqued-low.

2. Validez le nombre total de workers

Assurez-vous que le nombre combiné de workers Unicorn + Resque ne dépasse pas le nombre total de processeurs virtuels. Consultez File d’attente Unicorn supérieure à 200-300 pour obtenir des instructions sur la vérification de la configuration actuelle des workers.