Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-09-25. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Problembehandlung bei Ressourcenzuweisungsproblemen

Behandeln allgemeiner Ressourcenzuweisungsprobleme, die in Ihrer GitHub Enterprise Server-Anwendung auftreten können.

In diesem Artikel

Problembehandlung bei gängigen Ressourcenzuordnungsproblemen auf deiner Appliance

Note

Regelmäßig durchgeführte wiederholte Anforderungen (Abrufe) für Ihre GitHub Enterprise Server-Instance von CI-Systemen (Continuous Integration), Buildservern oder anderen Clients (z. B. Git- oder API-Clients) kann das System überfordern. Dies kann zu einem DoS-Angriff (Denial of Service) führen, was zu erheblichen Leistungsproblemen und zur Ressourcensättigung führt.

Um diese Probleme zu vermeiden, empfehlen wir dringend die Verwendung von Webhooks zum Empfangen von Updates. Webhooks ermöglichen es dem System, Updates automatisch an Sie zu übertragen, wodurch die Notwendigkeit eines konstanten Abrufs eliminiert wird. Darüber hinaus sollten Sie bedingte Anforderungen und Zwischenspeicherungsstrategien verwenden, um unnötige Anforderungen zu minimieren. Vermeiden Sie das Ausführen von Aufträgen in großen, gleichzeitigen Batches (so genannte Thundering Herds), und warten Sie stattdessen, bis Webhook-Ereignisse Aktionen auslösen.

Weitere Informationen findest du unter Informationen zu Webhooks.

Mit dem Überwachungs-Dashboard können Sie in Bezug auf die Ressourcenintegrität Ihrer Anwendung auf dem Laufenden bleiben und Entscheidungen treffen, wie Sie Probleme hinsichtlich hoher Nutzungen beheben können.

Bei systemkritischen Problemen und vor dem Vornehmen von Änderungen an Ihrer Anwendungen empfehlen wir dringend, dass Sie kontaktieren, indem Sie GitHub Enterprise Support besuchen und Ihr Supportpaket einschließen. Weitere Informationen finden Sie unter Daten für den GitHub Enterprise-Support bereitstellen.

Hohe CPU-Auslastung

Mögliche Ursachen

  • Die CPU Ihrer Instanz ist für Ihre Arbeitslast unzureichend bereitgestellt.
  • Das Upgrade auf eine neue Version von GitHub Enterprise Server erhöht aufgrund neuer Features häufig die CPU- und Arbeitsspeicherauslastung. Darüber hinaus können Migrations- oder Abstimmungshintergrundaufträge nach dem Upgrade vorübergehend die Leistung beeinträchtigen, bis sie abgeschlossen sind.
  • Erhöhte Anforderungen an Git oder API. Erhöhte Anforderungen an Git oder API können aufgrund verschiedener Faktoren auftreten, z. B. übermäßiges Repository-Klonen, CI/CD-Prozesse oder unbeabsichtigte Verwendung durch API-Skripts oder neue Workloads.
  • Erhöhte Anzahl von GitHub Actions-Aufträgen.
  • Erhöhte Anzahl von Git-Befehlen, die ein großes Repository ausgeführt haben.

Empfehlungen

Hohe Speicherauslastung

Mögliche Ursachen

  • Der Arbeitsspeicher Ihrer Instanz ist unzureichend bereitgestellt.
  • Erhöhte Anforderungen an Git oder API. Erhöhte Anforderungen an Git oder API können aufgrund verschiedener Faktoren auftreten, z. B. übermäßiges Repository-Klonen, CI/CD-Prozesse oder unbeabsichtigte Verwendung durch API-Skripts oder neue Workloads.
  • Einzelne Dienste, die ihre erwartete Speicherauslastung überschreiten und nicht genügend Arbeitsspeicher (Out Of Memory, OOM) ausführen.
  • Erhöhte Verarbeitung von Hintergrundaufträgen.

Empfehlungen

  • Der Arbeitsspeicher Ihrer Instanz ist für Ihre Arbeitslast und das Datenvolumen unzureichend bereitgestellt. Der fortlaufende Gebrauch könnte die empfohlenen Mindestanforderungen übersteigen.
  • Identifizieren Sie innerhalb der Nomad-Diagramme Dienste mit Trends für nicht genügend Arbeitsspeicher, denen häufig Trends mit freiem Speicherplatz folgen, nachdem sie neu gestartet wurden. Weitere Informationen findest du unter About the monitor dashboard.
  • Überprüfen Sie Protokolle auf Prozesse, die nicht mehr genügend Arbeitsspeicher haben, indem Sie rg -z 'kernel: Out of memory: Killed process' /var/log/syslog* ausführen (melden Sie sich hierfür zuerst mit SSH bei der administrativen Shell an – siehe „Auf die Verwaltungsshell (SSH) zugreifen“.)
  • Stellen Sie sicher, dass das richtige Verhältnis von Arbeitsspeicher zu CPU-Diensten erfüllt ist (mindestens 6.5:1).
  • Überprüfen Sie die Menge der Aufgaben, die für die Hintergrundverarbeitung in die Warteschlange eingereiht wurden – siehe „About the monitor dashboard“.

Niedrige Festplattenspeicherverfügbarkeit

Beide Speichervolumes, das eine am Stamm-Dateisystempfad (/) und das andere am Benutzer-Dateisystempfad (/data/user) eingehängt ist, können die Stabilität Ihrer Instanz beeinträchtigen, wenn nur wenig Speicherplatz verfügbar ist.

Das Stammspeichervolume wird in zwei gleich große Partitionen unterteilt. Eine der Partitionen wird als Stammdateisystem (/) bereitgestellt. Die andere Partition wird nur während Upgrades und Rollbacks von Upgrades als /mnt/ bereitgestellt, um bei Bedarf einfachere Rollbacks zu ermöglichen. Weitere Informationen findest du unter Systemübersicht.

Mögliche Ursachen

  • Dienstfehler, der zu einer erhöhten Anzahl von Protokollen führt
  • Hohe Datenträgerauslastung durch organischen Datenverkehr

Empfehlungen

  • Überprüfen Sie die Datenträgernutzung des /var/log-Ordners, indem Sie (sudo du -csh /var/log/*) ausführen oder manuell eine Protokollrotation (sudo logrotate -f /etc/logrotate.conf) erzwingen.
  • Überprüfen Sie den Datenträger auf große Dateien, die gelöscht wurden, aber weiterhin offenen Datei-Handles aufweisen (ghe-check-disk-usage).
  • Erhöhen Sie die Festplattenspeicherkapazität – siehe „Speicherkapazität erhöhen“.

Ungewöhnlich hohe Antwortzeiten

Mögliche Ursachen

  • Erhöhte Anforderungen an Git oder API. Erhöhte Anforderungen an Git oder API können aufgrund verschiedener Faktoren auftreten, z. B. übermäßiges Repository-Klonen, CI/CD-Prozesse oder unbeabsichtigte Verwendung durch API-Skripts oder neue Workloads.
  • Langsame Datenbankabfragen.
  • Erhöhte Ressourcennutzung des ElasticSearch-Dienstes nach dem Upgrade.
  • Erreichen der IOPS-Kontingente auf der Festplatte und/oder starke IO-Konflikte.
  • Gesättigte Worker.
  • Webhook-Übermittlungsverzögerungen.

Empfehlungen

  • Suchen Sie nach Spitzen oder anhaltend hohen Werten in den Diagrammen für ausstehende Festplattenoperationen: Anzahl der in die Warteschlange eingereihten Operationen.
  • Überprüfen Sie den Bereich App-Anforderung/Antwort, um festzustellen, ob nur bestimmte Dienste betroffen sind.
  • Überprüfen Sie nach einem Upgrade, ob Upgradeaufträge im Hintergrund abgeschlossen wurden, indem Sie ghe-check-background-upgrade-jobs ausführen.
  • Überprüfen Sie die Datenbankprotokolle auf langsame Abfragen in /var/log/github/exceptions.log (dazu melden Sie sich zunächst mithilfe von SSH bei der administrativen Shell an – siehe „Auf die Verwaltungsshell (SSH) zugreifen“), z. B. die zehn wichtigsten Anforderungen nach URL: grep SlowRequest github-logs/exceptions.log | jq '.url' | sort | uniq -c | sort -rn | head.
  • Überprüfen Sie das Diagramm für in die Warteschlange eingereihte Anforderungen auf bestimmte Worker, und passen Sie die Anzahl der aktiven Worker an.
  • Erhöhen Sie die Speicherdatenträger auf solche mit höherem IOPS/Durchsatz.
  • Überprüfen Sie die Menge der Aufgaben, die für die Hintergrundverarbeitung in die Warteschlange eingereiht wurden – siehe „About the monitor dashboard“.

Erhöhte Fehlerraten

Mögliche Ursachen

  • Erhöhte Anforderungen an Git oder API. Erhöhte Anforderungen an Git oder API können aufgrund verschiedener Faktoren auftreten, z. B. übermäßiges Repository-Klonen, CI/CD-Prozesse oder unbeabsichtigte Verwendung durch API-Skripts oder neue Workloads.
  • Fehlerhafter haproxy-Dienst oder Nichtverfügbarkeit einzelner Dienste.
  • Fehler bei der Netzwerkwartung des Repositorys im Laufe der Zeit.

Empfehlungen

  • Überprüfen Sie den Bereich App-Anforderung/Antwort, um festzustellen, ob nur bestimmte Dienste betroffen sind.
  • Überprüfen Sie die haproxy-Protokolle, und versuchen Sie zu ermitteln, ob böswillige Akteure die Ursache sein können.
  • Suchen Sie nach fehlgeschlagenen Wartungsaufträgen für Repositorynetzwerke (besuchen Sie http(s)://[hostname]/stafftools/networks).