Skip to main content

Enterprise Server 3.20 ist derzeit als Release Candidate verfügbar.

Problembehandlung von Ressourcenzuweisungsproblemen

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

Problembehandlung bei gängigen Ressourcenzuordnungsproblemen auf Ihrer Appliance

Hinweis

Regelmäßig durchgeführte wiederholte Anfragen (Polling) an Ihre GitHub Enterprise Server-Instance von CI-Systemen (Continuous Integration), Build-Servern oder anderen Clients (z. B. Git- oder API-Clients) können 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 dem System das automatische Übertragen von Updates an Sie, was konstante Abrufe überflüssig macht. 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 finden Sie unter Informationen zu Webhooks.

Mit dem Überwachungs-Dashboard können Sie über die Ressourcengesundheit Ihres Geräts informiert bleiben und Entscheidungen treffen, wie Sie Maßnahmen gegen Probleme mit hoher Auslastung ergreifen können, wie die auf dieser Seite beschriebenen.

Bei systemkritischen Problemen und bevor Sie Änderungen an Ihrem Gerät vornehmen, empfehlen wir Ihnen dringend, uns zu kontaktieren, indem Sie GitHub Enterprise-Support besuchen und Ihr Supportpaket beifügen. Weitere Informationen findest du unter Angeben von Daten für den GitHub Enterprise-Support.

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 hat ein großes Repository ausgeführt.

Empfehlungen

  • Stellen Sie sicher, dass CPU-Kerne entsprechend bereitgestellt werden.
  •         [Festlegen von Warnungsschwellenwerten](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/recommended-alert-thresholds).
    
  • Überprüfen Sie nach einem Upgrade, ob Upgradeaufträge im Hintergrund abgeschlossen wurden, indem Sie ghe-check-background-upgrade-jobs ausführen.
  • Verwenden Sie Webhooks anstelle von Pullen.
  • Verwenden Sie die API-Ratenbegrenzung.
  • Analysieren Sie die Git-Nutzung, indem Sie aktuelle Vorgänge und Git-Verkehr überprüfen.

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 überschreiten ihre erwartete Speichernutzung und geraten in einen Out-of-Memory-Zustand (OOM).
  • 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 finden Sie unter Über die Dashboards für die Überwachung.
  • Überprüfe Protokolle auf Prozesse, die nicht mehr über genügend Arbeitsspeicher verfügen, indem du rg -z 'kernel: Out of memory: Killed process' /var/log/syslog* ausführst. Melde dich hierfür zuerst mit SSH bei der Verwaltungsshell. Weitere Informationen findest du unter 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üfe die Anzahl der Aufgaben, die für die Hintergrundverarbeitung in die Warteschlange eingereiht wurden. Weitere Informationen findest du unter Über die Dashboards für die Überwachung.

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 bei Upgrades und Rollbacks von Upgrades als /mnt/Upgrade gemountet, um bei Bedarf einfachere Rollbacks zu ermöglichen. Weitere Informationen finden Sie 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 die Festplatte auf große Dateien, die gelöscht wurden, aber weiterhin offene Datei-Handles haben (ghe-check-disk-usage).
  • Erhöhe die Festplattenspeicherkapazität. Weitere Informationen findest du unter 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 erhebliche IO-Konflikte.
  • Gesättigte Arbeitskräfte.
  • 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üfe die Datenbankprotokolle auf langsame Anforderungen in /var/log/github/exceptions.log. Melde dich dazu zunächst mithilfe von SSH bei der Verwaltungsshell an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen. Du kannst z. B. die zehn langsamsten Anforderungen nach URL überprüfen: grep SlowRequest github-logs/exceptions.log | jq '.url' | sort | uniq -c | sort -rn | head.
  • Überprüfe den Warteschlangen-Graphen für bestimmte Worker und überlege, ob du die Anzahl der aktiven Worker anpassen solltest.
  • Erhöhen Sie die Speicherdatenträger auf solche mit höherem IOPS/Durchsatz.
  • Überprüfe die Anzahl der Aufgaben, die für die Hintergrundverarbeitung in die Warteschlange eingereiht wurden. Weitere Informationen findest du unter Über die Dashboards für die Überwachung.

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 Repository-Netzwerkwartung über einen längeren Zeitraum hinweg.

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.
  • Überprüfen Sie gescheiterte Wartungsaufträge für Repository-Netzwerke (besuchen Sie http(s)://[hostname]/stafftools/networks).