Résolution des problèmes d’allocation de ressources

Résolution des problèmes courants d’allocation de ressources sur votre appliance

Nous vous recommandons d'utiliser le tableau de bord du moniteur pour rester informé de l'état des ressources de votre appareil et prendre des décisions sur la manière de résoudre les problèmes d'utilisation élevée, tels que ceux décrits sur cette page.

Pour les problèmes critiques du système et avant d’apporter des modifications à votre appareil, nous vous recommandons vivement de nous contacter en visitant Support GitHub Enterprise et en incluant votre pack de support. Pour plus d’informations, consultez « Fourniture de données au support GitHub ».

Utilisation élevée du processeur

Causes possibles

• Le processeur de votre instance est sous-approvisionné pour votre charge de travail.
• La mise à niveau vers une nouvelle version de GitHub Enterprise Server augmente souvent l’utilisation du processeur et de la mémoire en raison de l'ajout de nouvelles fonctionnalités. En outre, la migration après la mise à niveau ou le processus d'arrière-plan de réconciliation peut dégrader temporairement la performance jusqu’à leur achèvement.
• Demandes en grand nombre contre Git ou l'API. Une augmentation des demandes adressées à Git ou à l’API peut se produire en raison de différents facteurs, tels que le clonage excessif du référentiel, les processus CI/CD ou l’utilisation involontaire par des scripts d’API ou de nouvelles charges de travail.
• Augmentation du nombre de tâches GitHub Actions.
• Un grand nombre de commandes Git ont été exécutées sur un dépôt volumineux.

Recommandations

• Vérifiez que les cœurs du processeur sont approvisionnés de manière appropriée.

•         [Définir les seuils d’alerte](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/recommended-alert-thresholds).
  

• Après une mise à niveau, vérifiez si les travaux de mise à niveau en arrière-plan sont terminés, en exécutant ghe-check-background-upgrade-jobs.
• Utilisez des webhooks plutôt que des pulls.
• Utilisez la limitation du débit d’API.
• Analysez l’utilisation de Git en vérifiant les opérations actuelles et le trafic Git.

Utilisation élévée de la mémoire

Causes possibles

• La mémoire de votre instance est sous-approvisionnée.
• Demandes en grand nombre contre Git ou l'API. Une augmentation des demandes adressées à Git ou à l’API peut se produire en raison de différents facteurs, tels que le clonage excessif du référentiel, les processus CI/CD ou l’utilisation involontaire par des scripts d’API ou de nouvelles charges de travail.
• Les services individuels dépassent leur consommation de mémoire prévue et rencontrent une erreur OOM (Out Of Memory).
• Augmentation du traitement des travaux en arrière-plan.

Recommandations

• La mémoire de votre instance est sous-approvisionnée pour votre charge de travail, le volume de données, étant donné que l’utilisation au fil du temps peut dépasser les exigences minimales recommandées.
• Dans les graphiques Nomad, repérez les services qui présentent des tendances de mémoire insuffisante, souvent suivies de tendances de mémoire libre après leur redémarrage. Pour plus d’informations, consultez « À propos du moniteur tableau de bord ».
• Vérifiez les journaux des processus sortant de la mémoire en cours d’exécution rg -z 'kernel: Out of memory: Killed process' /var/log/syslog* (pour cela, connectez-vous d’abord à l’interpréteur de commandes d’administration à l’aide de SSH : consultez Accès à l’interpréteur de commandes d’administration (SSH).)
• Vérifiez que le rapport correct de la mémoire aux services de processeur est atteint (au moins 6.5:1).
• Vérifiez la quantité de tâches mises en file d’attente pour le traitement en arrière-plan : consultez À propos du moniteur tableau de bord.

Peu d’espace disque disponible

Les deux volumes de stockage, l’un monté sur le chemin d’accès système de fichiers racine (/) et l’autre vers le chemin du système de fichiers utilisateur (/data/user) peuvent entraîner des problèmes de stabilité de votre instance si un espace disque faible est disponible.

N'oubliez pas que le volume de stockage racine est divisé en deux partitions de même taille. L’une des partitions est montée comme système de fichiers racine (/). L’autre partition est montée uniquement lors des mises à niveau et des annulations de mise à niveau en tant que mise à niveau /mnt/ afin de faciliter les restaurations si nécessaire. Pour plus d’informations, consultez « Vue d’ensemble du système ».

Causes possibles

• Défaillance d’un service entraînant une augmentation du volume des journaux d’activité
• Utilisation élevée du disque via le trafic organique

Recommandations

• Vérifiez l’utilisation du disque du dossier /var/log en exécutant (sudo du -csh /var/log/*) ou forcez manuellement une rotation des journaux (sudo logrotate -f /etc/logrotate.conf).
• Vérifiez que le disque ne contient pas de fichiers volumineux qui ont été supprimés mais dont les handles de fichiers (ghe-check-disk-usage) sont encore ouverts.
• Augmenter la capacité de stockage sur disque - consultez Augmentation de la capacité de stockage.

Temps de réponse plus longs que la normale

Causes possibles

• Demandes en grand nombre contre Git ou l'API. Une augmentation des demandes adressées à Git ou à l’API peut se produire en raison de différents facteurs, tels que le clonage excessif du référentiel, les processus CI/CD ou l’utilisation involontaire par des scripts d’API ou de nouvelles charges de travail.
• Requêtes de base de données lentes.
• Après la mise à niveau, ElasticSearch a augmenté l'utilisation des ressources de service.
• Atteinte des quotas IOPS du disque et/ou forte contention IO.
• Travailleurs surchargés.
• Retards de livraison du webhook.

Recommandations

• Recherchez des pics ou des nombres soutenus dans les graphiques des opérations en attente sur disque : nombre d’opérations mises en file d’attente.
• Vérifiez le panneau requête-réponse de l’application pour voir si seuls certains services sont affectés.
• Après une mise à niveau, vérifiez si les travaux de mise à niveau en arrière-plan sont terminés, en exécutant ghe-check-background-upgrade-jobs.
• Vérifiez les journaux de base de données pour les requêtes lentes dans /var/log/github/exceptions.log (pour cela, connectez-vous d’abord à l’interpréteur de commandes d’administration à l’aide de SSH : consultez Accès à l’interpréteur de commandes d’administration (SSH)), par exemple en vérifiant les 10 principales requêtes lentes par URL : grep SlowRequest github-logs/exceptions.log | jq '.url' | sort | uniq -c | sort -rn | head.
• Vérifiez le graphique des demandes mises en file d’attente pour certains travailleurs et envisagez d’ajuster leur nombre de travailleurs actifs.
• Augmentez les disques de stockage à ceux avec des IOPS/débit plus élevés.
• Vérifiez la quantité de tâches mises en file d’attente pour le traitement en arrière-plan : consultez À propos du moniteur tableau de bord.

Taux d’erreur élevés

Causes possibles

• Demandes en grand nombre contre Git ou l'API. Une augmentation des demandes adressées à Git ou à l’API peut se produire en raison de différents facteurs, tels que le clonage excessif du référentiel, les processus CI/CD ou l’utilisation involontaire par des scripts d’API ou de nouvelles charges de travail.
• Échec du service haproxy ou indisponibilité des services individuels.
• Échec de la maintenance du réseau du référentiel au fil du temps.

Recommandations

• Vérifiez le panneau requête-réponse de l’application pour voir si seuls certains services sont affectés.
• Vérifiez les journaux haproxy et essayez d’identifier si des acteurs malveillants peuvent en être la cause.
• Vérifiez la présence de travaux de maintenance du réseau du référentiel ayant échoué (visitez http(s)://[hostname]/stafftools/networks).