Diese Version von GitHub Enterprise Server wird eingestellt am 2026-03-17. 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.

Überprüfen der Systemkapazität vor dem Upgrade

Vor dem Upgrade von GitHub Enterprise Server solltest du diese Kapazitätsprüfungen durchführen und die empfohlenen Schritte ausführen.

In diesem Artikel

Ein Upgrade auf neuere Versionen von GitHub Enterprise Server erhöht in der Regel den Ressourcenverbrauch. Mit jedem Featurerelease kommen neue Funktionen hinzu, einige sind standardmäßig aktiviert, andere müssen aktiviert werden, was mehr Verarbeitungsleistung erfordert. Kundennutzungsmuster wirken sich auch auf die Nachfrage aus. Beispielsweise können Unternehmen mit Zehntausenden von Organisationen eine höhere Ressourcennutzung feststellen.

Ressourcenerhöhungen werden am häufigsten als höhere CPU-Auslastung, mehr E/A-Vorgänge pro Sekunde (IOPS), größere Speicherauslastung oder größere Backlogs für Aqueduct-Warteschlangen angezeigt. Als Vorbereitung auf diese Änderungen überprüfst du die verfügbare Kapazität deines Systems und wendest vor dem Upgrade alle Empfehlungen zur Problembehebung an. Führe diese Überprüfungen zu den arbeitsstärksten Tages- und Wochenzeiten durch, um die genauesten Ergebnisse zu erhalten.

Ressourcenanforderungen

Vor dem Upgrade deiner Instanz ist es wichtig zu überprüfen, ob das System die erforderlichen Ressourcenanforderungen erfüllt:

  1. CPU-Auslastung unter 70 %
  2. Arbeitsspeicherauslastung unter 70 %
  3. Datenträger nicht gesättigt
  4. Unicorn-Warteschlange unter 200–300
  5. Aqueduct-Backlog unter 1–2 Stunden

CPU-Auslastung unter 70 %

  1. Überprüfe die CPU-Auslastung. Wechsle in der Verwaltungskonsole zur Überwachungsseite (https://HOSTNAME.com:8443/setup/monitor), und sieh dir das Diagramm CPU an.

    • Wenn die Auslastung regelmäßig unter 70 % liegt, fahre mit Memory usage fort.
    • Wenn die Auslastung regelmäßig über 70 % liegt, erfüllt das System die Kriterien für das Upgrade nicht.

  2. Vergleiche die Auslastung mit der durchschnittlichen CPU-Auslastung. Der Vergleich hilft bei der Identifizierung einer möglichen Datenträgersättigung.

    • Klicke im Load-Diagramm auf short-term, um nur die Linie der kurzfristigen Entwicklung anzuzeigen. Suche den Spitzenlastwert.

    • Klicke im CPU-Diagramm auf idle, um nur die Leerlauflinie anzuzeigen. Notiere den Leerlaufwert zum gleichen Zeitstempel.

    • Berechne die Auslastung:

      100 – idle

    • Berechne den durchschnittlichen Prozentsatz der Auslastung:

      (peak load value ÷ number of vCPUs) × 100

  3. Interpretiere die Ergebnisse.

    Wenn der durchschnittliche Prozentsatz der CPU-Auslastung mehr als 50 % über der Auslastung liegt, deutet dies auf Ressourcenkonflikte hin. Fahre erst mit dem Upgrade fort, nachdem du die mögliche Datenträgersättigung untersucht hast (siehe Datenträger nicht gesättigt).

Arbeitsspeicherauslastung unter 70 %

  1. Überprüfe auch die Arbeitsspeicherauslastung. Wechsle in der Verwaltungskonsole zur Überwachungsseite (https://HOSTNAME.com:8443/setup/monitor), und sieh dir das Diagramm Memory an.

  2. Interpretiere die Ergebnisse.

    • Wenn die Arbeitsspeicherauslastung regelmäßig unter 70 % liegt, fahre mit Datenträger nicht gesättigt fort.
    • Wenn die Arbeitsspeicherauslastung regelmäßig über 70 % liegt, erfüllt das System die Kriterien für das Upgrade nicht.

Datenträger nicht gesättigt

  1. Überprüfe die Anbieterspezifikationen. Wenn der Cloud- oder Hardwareanbieter Metriken zur Datenträgerauslastung bereitstellt, nutze diese, um zu prüfen, ob der Datenträger gesättigt ist.

    • Wenn keine Metriken verfügbar sind, fordere die Datenträgerspezifikationen von deinem Anbieter an, einschließlich des maximalen Durchsatzes und der maximalen IOPS-Anzahl.
    • Vergleiche diese Grenzwerte mit der beobachteten Datenträgerauslastung. Wenn sich die Auslastung dem Höchstwert nähert, ist der Datenträger gesättigt.

  2. Überprüfe die Datenträgerdiagramme in der Verwaltungskonsole. Wechsle zur Seite „Monitor“ (https://HOSTNAME.com:8443/setup/monitor).

    • Zeige die Diagramme Disk Operations und Disk Traffic an.

    • Vergleiche die Werte der Y-Achse mit den Spezifikationen deines Anbieters (nicht mit der im Diagramm gezeigten maximalen Skala).

    • Überprüfe sowohl Daten- als auch Stammdatenträger.

Diese Diagramme sind auf der Seite „Monitor“ in den Standarddashboards verfügbar.

  1. Interpretiere die Ergebnisse. Wenn sich die Datenträgerauslastung dem vom Anbieter definierten Höchstwert nähert, ist der Datenträger gesättigt. In diesem Fall erfüllt das System die Kriterien für das Upgrade nicht.

Unicorn-Warteschlange unter 200–300

  1. Überprüfe das Diagramm zu den Anforderungen in der Warteschlange. Wechsle in der Verwaltungskonsole zur Überwachungsseite (https://HOSTNAME.com:8443/setup/monitor), und sieh dir das Diagramm Queued Requests an.

Dieses Diagramm ist auf der Seite „Monitor“ in den Standarddashboards verfügbar.

  1. Interpretiere die Ergebnisse.

    • Wenn die Zahl der Anforderungen in der Warteschlange konsistent unter 200 liegt, fahre mit Aqueduct-Backlog unter 1–2 Stunden fort.
    • Wenn die Zahl der Anforderungen in der Warteschlange regelmäßig bei oder über 200–300 liegt, erfüllt das System die Kriterien für das Upgrade nicht.

  2. Optional: Überprüfe die Auslastung der Unicorn-Worker. Führe über die Verwaltungsshell Folgendes aus:

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

    Sieh dir die letzte Spalte der Ausgabe an. Wenn alle Prozesse > 90% utilization anzeigen, sind weitere Unicorn-Worker erforderlich.

Aqueduct-Backlog unter 1–2 Stunden

  1. Überprüfe die Aqueduct-Warteschlangentiefe. Wechsle in der Verwaltungskonsole zur Überwachungsseite (https://HOSTNAME.com:8443/setup/monitor), und sieh dir das Diagramm Aqueduct queue depth an.

Dieses Diagramm ist auf der Seite „Monitor“ in den Standarddashboards verfügbar.

  1. Interpretiere die Ergebnisse.

    • Wenn der Backlog weniger als 1–2 Stunden dauert, erfülle diese Anforderung.
    • Wenn der Backlog regelmäßig länger als 1–2 Stundendauert, erfüllt das System die Kriterien für das Upgrade nicht.

  2. Überwache die index_high-Warteschlange. Bei großen Bereitstellungen kann es zu einem erheblichen Anstieg der index_high-Warteschlangentiefe kommen, wodurch Backlogs verstärkt werden können. Achte bei der Überwachung besonders auf diese Warteschlange.

Wenn alle Kriterien (CPU, Arbeitsspeicher, Datenträger, Unicorn-Warteschlange, Aqueduct-Backlog) erfüllt sind, kannst du mit dem Upgrade auf die Zielfeatureversion fortfahren. Gehe nach dem Upgrade davon aus, dass der Ressourcenverbrauch weiter steigt.

Wenn Kriterien nicht erfüllt sind, behebe die zugrunde liegenden Probleme, bevor du versuchst, ein Upgrade durchzuführen.

Upgrade von Hardware und Optimieren von Workern

Wenn das System mindestens eine der Ressourcenanforderungen nicht erfüllt hat, muss die Kapazität vor dem Upgrade erhöht werden. In den folgenden Abschnitten wird beschrieben, wie Hardwareressourcen hinzugefügt und die Workerkonfiguration angepasst werden können, um häufige Engpässe zu beheben.

  1. CPU über 70 %
  2. Arbeitsspeicher über 70 %
  3. Datenträger gesättigt
  4. Unicorn-Warteschlange über 200–300
  5. Aqueduct-Backlog über 1–2 Stunden

CPU über 70 %

Wenn die CPU-Auslastung regelmäßig über 70 % liegt:

  • Erhöhe die CPU-Ressourcen. Füge mindestens 20 % mehr vCPUs hinzu.
  • Konto für neue Worker. Ordne 1 vCPU pro Worker zu. Wenn du beispielsweise 5 Unicorn-Worker und 10 Resque-Worker hinzufügst, erhöhe die Anzahl der vCPUs um mindestens 15.

Arbeitsspeicher über 70 %

Wenn die Arbeitsspeicherauslastung regelmäßig über 70 % liegt:

  • Erhöhe den Arbeitsspeicher. Füge zusätzlichen RAM hinzu, damit die durchschnittliche Auslastung auf unter 70 % reduziert wird.
  • Konto für neue Worker. Ordne 1 GB Arbeitsspeicher pro Worker zu. Wenn du beispielsweise 5 Unicorn-Worker und 10 Resque-Worker hinzufügst, erhöhe den Arbeitsspeicher um mindestens 15 GB.

Datenträger gesättigt

Wenn die Überprüfung der Datenträgersättigung eine Sättigung bestätigt, führe ein Upgrade auf Datenträger mit höherem Durchsatz und maximaler IOPS-Anzahl durch.

Unicorn-Warteschlange über 200–300

Wenn Unicorn-Anforderungen konsistent über 200–300 in die Warteschlange eingereiht werden, musst du möglicherweise weitere Unicorn-Worker hinzufügen. Führe die folgenden Schritte aus, um die Gesamtzahl der Worker zu ermitteln und die Konfiguration zu aktualisieren.

1. Schätzen zusätzlicher Worker

Führe den folgenden Befehl während der Spitzenzeiten aus, um die Auslastung pro Worker anzuzeigen:

ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

Beispielausgabe:

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

Die durchschnittliche Anzahl von Anforderungen pro Sekunde beträgt 12 Anforderungen/Sek.

Berechne aus dieser Ausgabe die durchschnittlichen Anforderungen pro Sekunde.

  • Im obigen Beispiel sind das: 12 Anforderungen/Sek.

  • Ziel ist es, Anforderungen in der Warteschlange auf höchstens 100 zu reduzieren.

  • Formel:

    (Queued requests – 100) ÷ avg req/s

  • Beispiel: (280 – 100) ÷ 12 = 15 zusätzliche Worker werden benötigt.

    Tipp

    Wenn du eine Bestätigung der Ergebnisse benötigst, kannst du dich an uns wenden. Besuche dazu GitHub Enterprise Support, lade ein Paket hoch und frage nach der Gesamtzahl der Unicorn-Worker.

2. Überprüfen der aktuellen Konfiguration

Stelle sicher, dass die Gesamtzahl der Worker (Unicorn + Resque) die Anzahl der vCPUs nicht überschreitet. Ordne zumindest 1 vCPU pro Worker zu.

Überprüfe die aktuelle Anzahl:

  • Unicorn-Worker

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git | wc -l

    Füge diesem Wert die berechnete Anzahl neuer Worker hinzu, um die benötigte Gesamtzahl zu erhalten.

  • Resque-Worker

    ps -ef | grep aqueduct-1.1.0 | grep -v "grep aqueduct-1.1.0" | wc -l

3. Anpassen der Konfiguration

Wenn die Summe der Unicorn- und Resque-Worker die Anzahl der vCPUs überschreitet, musst du weitere vCPUs hinzufügen, bevor du fortfährst.

Aktualisiere die Anzahl der Unicorn-Worker:

ghe-config app.github.github-workers <NUM-WORKERS>
ghe-config-apply

Ersetze durch die Gesamtzahl der Unicorn-Worker.

Aqueduct-Backlog über 1–2 Stunden

Wenn Aqueduct-Jobs für mehr als 1–2 Stunden regelmäßig im Rückstand sind, füge Worker mit niedriger Resque-Warteschlange hinzu, um das Risiko von Warteschlangensicherungen zu verringern. Dieses Problem tritt nach dem Upgrade häufiger auf.

1. Hinzufügen von Worker mit niedriger Resque-Warteschlange

  • Erhöhe die Anzahl der Worker um 5–10. Achte auf die CPU-Kapazität – jeder Worker benötigt mindestens 1 vCPU.
ghe-config app.github.resqued-low-workers <NUM-WORKERS>
ghe-config-apply

Ersetze durch die neue Gesamtanzahl von Worker mit niedriger Resque-Warteschlange.

2. Überprüfen der Gesamtanzahl von Workern

Stelle sicher, dass die Anzahl von Unicorn- und Resque-Workern zusammengenommen die Gesamtzahl der vCPUs nicht überschreitet. Anweisungen zum Überprüfen der aktuellen Workerkonfiguration findest du unter Unicorn-Warteschlange über 200–300.