Cette version de GitHub Enterprise Server n'est plus disponible depuis 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 %](#cpu-usage-below-70)

  2.        [Utilisation de la mémoire inférieure à 70 %](#memory-usage-below-70)

  3.        [Disque non saturé](#disk-not-saturated)

  4.           [File d’attente Unicorn inférieure à 200-300](#unicorn-queue-under-200300)

  5.           [Backlog Aqueduct inférieur à 1-2 heures](#aqueduct-backlog-under-12-hours)

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.
  1.           **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

  1.        **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.

  1.        **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é.
  1.           **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.**

  2.           **Facultatif : contrôlez l’utilisation des workers Unicorn.**

    Depuis la console d'administration, 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 travailleurs 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 précis 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 travailleurs pour résoudre les points de blocage courants.

  1.        [Processeur supérieur à 70 %](#cpu-above-70)

  2.        [Mémoire supérieure à 70 %](#memory-above-70)

  3.        [Disque saturé](#disk-saturated)

  4.           [File d’attente Unicorn supérieure à 200-300](#unicorn-queue-above-200300)

  5.           [Retard d'Aqueduct de plus de 1 à 2 heures](#aqueduct-backlog-above-12-hours)

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 travailleurs. Allouez 1 processeur virtuel par travailleur. Par exemple, si vous ajoutez 5 workers Unicorn et 10 workers Resque, augmentez les vCPU 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 travailleurs. 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 mises en file d’attente au-delà de 200-300, l’ajout de workers Unicorn supplémentaires peut s’avérer nécessaire. Suivez ces étapes pour déterminer le nombre total de travailleurs cible et mettre à jour votre configuration.

1. Estimez le nombre de travailleurs 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 valider vos conclusions, vous pouvez nous contacter via Support GitHub Enterprise, en téléchargeant un bundle et en demandant le nombre total cible de travailleurs Unicorn.

2. Vérifiez la configuration actuelle

Vérifiez que le nombre total de travailleurs (Unicorn + Resque) ne dépasse pas le nombre de vCPU. Attribuez au minimum 1 vCPU par travailleur.

Vérifiez le nombre actuel :

  • Travailleurs de licornes

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

    Ajoutez votre nombre calculé de nouveaux travailleurs à cette valeur pour obtenir l'objectif total.

  • Travailleurs Resque

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

3. Ajustez la configuration

Si le total des travailleurs Unicorn + Resque excède le nombre de vCPU, ajoutez des vCPU supplémentaires avant de poursuivre.

Mettre à jour le nombre de travailleurs unicorne :

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

Remplacez par le nombre total de travailleurs Unicorn cible.

Le retard d'Aqueduct est supérieur à 1 - 2 heures

Si les tâches Aqueduct restent régulièrement en backlog pendant plus d’une à deux heures, ajoutez des travailleurs Resque-low afin de réduire le risque d’accumulation dans la file d’attente. Ce problème s’aggrave souvent après une mise à niveau.

1. Ajoutez des travailleurs Resque-low

  • Augmentez le nombre de travailleurs 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 travailleurs Resque-low.

2. Validez le nombre total de travailleurs

Vérifiez que le nombre combiné de travailleurs Unicorn + Resque ne dépasse pas le nombre total de vCPU. Consultez la section « File d’attente Unicorn supérieure à 200-300 » afin d’obtenir les instructions pour vérifier la configuration actuelle des travailleurs.