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.

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.        [File d'attente Aqueduct de 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.

  • Accédez à la vue Intégrité opérationnelle et vérifiez le graphique Load.

  • Dans la matrice, trouvez la valeur où la ligne shortterm croise la colonne avg.

  • Calculez le pourcentage moyen de charge :

    (short-term avg ÷ number of vCPUs) × 100

  • Dans la même vue, vérifiez le graphique CPU. Dans la matrice, trouvez la valeur où la ligne idle croise la colonne avg. Soustrayez cette valeur de 100 pour obtenir le taux d'utilisation.

  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 la vue « Système et Application Insights ».

  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 la vue « Système et Application Insights ».

  1.        **Interprétez les résultats.**
    • Si les requêtes en file d’attente sont constamment inférieures à 200, restez avec un retard Aqueduct qui n’excède pas 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 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.

### Le backlog d'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 est disponible dans la vue « Système et Application Insights ».


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.

1. 
              **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 optimisation des unités de traitement

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)
1. 
           [Mémoire supérieure à 70 %](#memory-above-70)
1. 
           [Disque saturé](#disk-saturated)
1. 
           [File d’attente Unicorn supérieure à 200–300](#unicorn-queue-above-200300)
1. 
           [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 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 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 en file d’attente au‑delà de 200–300, vous devrez peut-être ajouter davantage de workers unicorns. 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 :

```shell
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 paquet et en demandant le nombre total cible de travailleurs Unicorn.

2. Vérifiez la configuration actuelle

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

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 la somme des workers Unicorn + Resque dépasse le nombre de processeurs virtuels, vous devrez ajouter davantage de processeurs virtuels avant de continuer.

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 sont régulièrement en attente pendant plus de 1 ou 2 heures, ajoutez des workers resqued-low pour réduire le risque d'engorgement des files d’attente. Ce problème s’aggrave souvent après une mise à niveau.

Ajoutez des travailleurs à faibles priorités de secours

  • 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 requalifiés bas.

2. Validez le nombre total de travailleurs

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