Résolution des problèmes courants d’allocation de ressources sur votre appliance
Remarque
Les demandes répétées (polling) adressées à votre instance GitHub Enterprise Server par les systèmes d'intégration continue (CI), les serveurs de construction ou d'autres clients (tels que les clients Git ou API) peuvent submerger le système. Cela peut entraîner une attaque par déni de service (DoS), provoquant des problèmes de performances significatifs et une saturation des ressources.
Pour éviter ces problèmes, nous vous recommandons vivement d’utiliser des webhooks pour recevoir des mises à jour. Les webhooks permettent au système d’envoyer automatiquement des mises à jour à vous, et cela élimine la nécessité d’un sondage constant. En outre, envisagez d’utiliser des demandes conditionnelles et des stratégies de mise en cache pour réduire les demandes inutiles. Évitez d’exécuter des travaux en grandes quantités de manière simultanée (avalanche de requêtes) et attendez plutôt que les événements de webhook déclenchent des actions.
Pour plus d’informations, consultez « AUTOTITLE ».
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, voir Fournir des données à GitHub Enterprise Support .
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.
- Après une mise à niveau, vérifiez si les travaux de mise à niveau en arrière-plan sont terminés, en exécutant .
- Utilisez des webhooks au lieu de l’extraction.
- 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.
- Requêtes augmentées 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, identifiez les services avec des problèmes de mémoire insuffisante qui sont souvent suivis par des tendances de mémoire libérée après leur redémarrage. Pour plus d’informations, consultez « AUTOTITLE ».
- Vérifiez les journaux des processus sortant de la mémoire en cours d’exécution (pour cela, connectez-vous d’abord à l’interpréteur de commandes d’administration à l’aide de SSH : consultez AUTOTITLE.)
- Vérifiez que le rapport correct de la mémoire aux services de processeur est atteint (au moins ).
- Vérifiez la quantité de tâches mises en file d’attente pour le traitement en arrière-plan : consultez AUTOTITLE.
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 () 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 n'est montée que pendant les mises à niveau et les retours en arrière des mises à niveau , afin de faciliter les retours en arrière si nécessaire. Pour plus d’informations, consultez « AUTOTITLE ».
Causes possibles
- Échec du service provoquant une augmentation de la quantité de fichiers journaux
- Utilisation élevée du disque via le trafic organique
Recommandations
- Vérifiez l’utilisation du dossier en exécutant () ou en forçant manuellement une rotation du journal ().
- Vérifiez que le disque ne contient pas de fichiers volumineux qui ont été supprimés mais dont les handles de fichiers () sont encore ouverts.
- Augmenter la capacité de stockage sur disque - consultez AUTOTITLE.
Temps de réponse plus longs que la normale
Causes possibles
- Requêtes augmentées 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 d’E/S par seconde sur le disque et/ou une forte contention d'E/S.
- Travailleurs surchargés.
- Retards de livraison du webhook.
Recommandations
- Recherchez des pics ou des nombres soutenus dans les opérations disque en attente : 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 .
- Vérifiez les journaux des bases de données pour détecter les requêtes lentes (pour cela, connectez-vous d’abord à l’interpréteur de commandes d’administration à l’aide de SSH - consultez AUTOTITLE), par exemple en vérifiant les 10 requêtes les plus lentes par URL.
- 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 AUTOTITLE.
Taux d’erreur élevés
Causes possibles
- Requêtes augmentées 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 ou de la non-disponibilité 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 et essayez d'identifier si des acteurs malveillants peuvent être la cause.
- Recherchez les travaux de maintenance réseau du référentiel ayant échoué (visitez ).