Analysieren des Git-Datenverkehrs auf Ihrer GitHub Enterprise Server Instanz

Über Gouverneur

Gouverneur ist ein integrierter Monitor für Git-Aktivitäten in Ihrer Instanz. Verwenden Sie den ghe-governor Befehl, um zu sehen, welche Repositorys, Benutzer, IP-Adressen und Git-Vorgänge Ladevorgänge erstellen.

Verwenden Sie diese Daten, wenn die CPU-, Arbeitsspeicher- oder Datenträgerauslastung zunimmt, und Sie müssen bestätigen, ob Git-Datenverkehr die Ursache ist. Informationen zu Befehlssyntax und Unterbefehlen finden Sie unter Befehlszeilenwerkzeuge.

Governor zeichnet nur Git-Vorgänge auf. Es enthält keine API oder Webdatenverkehr. Informationen zum Überprüfen aktuell ausgeführter Vorgänge finden Sie im Hilfsprogramm ghe-btop in Befehlszeilenwerkzeuge.

Informationen zu Gouverneursdatendateien

Governor speichert seine Daten in Dateien unter /data/user/governor/. Jede Datei enthält eine Stunde Daten und wird für zwei Wochen aufbewahrt. Die Dateinamen enthalten Unix-Zeitstempel, die den Zeitraum der einzelnen Dateien angeben.

Um den Datenbereich zu bestätigen, der aktuell auf dem Datenträger gespeichert ist, konvertieren Sie die Zeitstempel in den frühesten und neuesten Dateinamen in lesbare Daten.

for epoch in $(sudo ls /data/user/governor/ 2>/dev/null | grep '^governor\.' | sort | sed -n '1p;$p' | cut -f2 -d.); do echo "${epoch} = $(date -d @${epoch})"; done

Die Ausgabe zeigt die Startzeit der frühesten und neuesten Datendateien an.

1551186000 = Tue Feb 26 13:00:00 UTC 2019
1552392000 = Tue Mar 12 12:00:00 UTC 2019

Bevor du anfängst

Bevor Sie Gouverneursabfragen ausführen, sammeln Sie diese Informationen:

• SSH-Zugriff auf die Appliance. Sie benötigen Zugriff auf die administrative Shell, um ghe-governor auszuführen. Siehe Auf die Verwaltungsshell (SSH) zugreifen.
• Welcher Knoten abfragt werden soll. Beginnen Sie bei eigenständigen oder Hochverfügbarkeitsbereitstellungen auf dem primären Knoten. Führen Sie für Cluster Abfragen für jeden git-server Knoten aus, da kein einzelner Knoten den gesamten Git-Datenverkehr enthält.
• Das Auswirkungsfenster. Beachten Sie die Start- und Endzeiten der gemeldeten Beeinträchtigung, damit Sie Abfragen mit -t und -u eingrenzen können.
• Namen von Repositorys oder Organisationen, wenn Benutzer Probleme mit bestimmten Repositorys oder Organisationen gemeldet haben.

Ermitteln, ob Git zum Laden beiträgt

Beginnen Sie mit einem allgemeinen Überblick und ordnen Sie dann die Auslastung bestimmten Repositories oder Programmen zu.

• Fassen Sie alle letzten Git-Aktivitäten in Ihrer Instanz zusammen:

  ghe-governor health
  

• Suchen Sie Repositorys mit der langsamsten durchschnittliche Antwortzeit:

  ghe-governor aggregate repo avg_rt
  

• Suchen sie Repositorys mit dem längsten einzelnen Vorgang:

  ghe-governor aggregate repo max_rt
  

• Ermitteln der langsamsten einzelnen Vorgänge (nicht gruppiert):

  ghe-governor top rt -n 50
  

• Suchen Sie die Repositorys, die die meiste CPU-Zeit verbrauchen:

  ghe-governor aggregate repo cpu
  

• Für ein Repository, das hervorsticht, finden Sie, welches Git-Unterprogramm für die CPU-Auslastung verantwortlich ist:

  ghe-governor aggregate program cpu -r OWNER/REPOSITORY
  

• Suchen Sie die Repositories, in denen pack-objects die meiste CPU-Zeit verbraucht hat. Das pack-objects Programm bündelt Daten, die während Klon- und Abrufvorgängen an Clients gesendet werden; eine hohe Anzahl belastet die CPU und den Arbeitsspeicher der Appliance erheblich:

  ghe-governor aggregate repo cpu -P pack-objects
  

• Suchen Sie die einzelnen Vorgänge, die die meiste CPU-Zeit verwendet haben (nicht gruppiert):

  ghe-governor top cpu -n 50
  

• Suchen Sie die Repositorys, die die meisten Datenträgerschreibvorgänge während eines bestimmten Zeitintervalls steuern:

  ghe-governor aggregate repo disk_write_kb -t START-TIME -u END-TIME
  

• Überprüfen Sie auf hohe Parallelität, was angibt, dass viele Git-Vorgänge gleichzeitig ausgeführt werden:

  ghe-governor aggregate repo max_parallelism
  

Wenn die Ergebnisse auf ein bestimmtes Repository oder Programm verweisen, fahren Sie mit dem entsprechenden Abschnitt unten fort.

Identifizieren des häufigsten Klons und Abrufen von Datenverkehr

Das upload-pack Programm verarbeitet Daten, die bei Klon- und Abrufvorgängen an Clients ausgeliefert werden. Verwenden Sie diese Abfragen, um zu ermitteln, welche Repositorys, Benutzer und IP-Adressen die meisten Klon- und Abrufaktivitäten steuern.

• Anzahl der Klon- und Fetch-Vorgänge nach Repository:

  ghe-governor aggregate repo count -P upload-pack
  

• Identifizieren Sie Benutzer, die Klon- und Abrufvorgänge ausführen, und zählen Sie ihre Vorgänge:

  ghe-governor aggregate user_id count -P upload-pack
  

• Identifizieren Sie die IP-Adressen, die die meisten Klon- und Abrufanforderungen generieren. Eine kleine Anzahl von IP-Adressen mit hoher Häufigkeit weist häufig auf eine CI-Runner-Flotte hin:

  ghe-governor aggregate ip count -P upload-pack
  

• Messen Sie das Gesamtvolumen der pro Repository bereitgestellten Daten:

  ghe-governor aggregate repo uploaded_kb -P upload-pack
  

• Messen Sie das durchschnittliche Datenvolumen, das pro Benutzer hochgeladen wurde:

  ghe-governor aggregate user_id avg_uploaded -P upload-pack
  

• Ermitteln Sie die maximale Klon- und Abrufparallelität pro Repository. In der MAXPL Spalte wird die höchste Anzahl gleichzeitiger Vorgänge angezeigt, die für jedes Repository aufgezeichnet werden. Ein hoher Wert für eine kleine Anzahl von Repositories deutet auf ein Thundering-Herd-Problem hin:

  ghe-governor aggregate repo max_parallelism -P upload-pack
  

• Suchen Sie nach den größten einzelnen Clone- oder Fetch-Vorgängen (nicht gruppiert):

  ghe-governor top uploaded -P upload-pack -n 50
  

Push-lastigen Datenverkehr identifizieren

Die Programme receive-pack und spokes-receive-pack verarbeiten Daten, die bei Push-Vorgängen von Clients empfangen werden. Verwenden Sie diese Abfragen, um zu ermitteln, welche Repositorys, Benutzer und IP-Adressen die meisten Pushaktivitäten generieren.

• Anzahl der Push-Vorgänge nach Repository:

  ghe-governor aggregate repo count -P receive-pack -P spokes-receive-pack
  

• Identifizieren Sie Benutzer, die an eine Organisation pushen, und zählen Sie ihre Pushvorgänge:

  ghe-governor aggregate user_id count -o ORGANIZATION -P receive-pack -P spokes-receive-pack
  

• Messen Sie das Gesamtvolumen der empfangenen Daten pro Repository:

  ghe-governor aggregate repo received_kb -P receive-pack -P spokes-receive-pack
  

• Identifizieren Sie IP-Adressen, die die meisten Pushdaten senden:

  ghe-governor aggregate ip received_kb -P receive-pack -P spokes-receive-pack
  

• Suchen sie nach den größten einzelnen Pushvorgängen (nicht gruppiert):

  ghe-governor top received -P receive-pack -P spokes-receive-pack -n 50
  

Einschränken der Analyse

Sie können einem ghe-governor top- oder ghe-governor aggregate-Befehl eine beliebige Kombination der folgenden Optionen hinzufügen, um die Abfrage auf ein bestimmtes Zeitfenster, Repository, einen bestimmten Inhaber oder ein bestimmtes Programm einzuschränken.

Zeitfilter

Option	Description
-t <timespec>	Erwägen Sie nur Vorgänge seit einer bestimmten Startzeit. Der Standardwert ist vor 48 Stunden.
-u <timespec>	Erwägen Sie nur Vorgänge bis zu einer bestimmten Endzeit. Der Standardwert ist die aktuelle Uhrzeit.

Die folgenden Formate werden für <timespec> akzeptiert.

Format	Example	Bedeutung
Unix-Zeitstempel	-t 1371614483	Sekunden seit dem 1. Januar 1970
Java Zeitstempel	-t 1371614483637	Millisekunden seit dem 1. Januar 1970
Relative Tage	-t 1d	Der letzte Tag
Relative Stunden	-t 2h	Die letzten zwei Stunden
Relative Minuten	-t 20m	Die letzten zwanzig Minuten

Geltungsbereichsfilter

Option	Description
-r <owner>/<repository>	Erwägen Sie nur Vorgänge, die einem bestimmten Besitzer und Repository entsprechen. Geben Sie diese Option mehrmals an, um mehreren Repositorys zu entsprechen.
-o <owner>	Erwägen Sie nur Vorgänge, die einem bestimmten Besitzer entsprechen, z. B. einem Benutzer oder einer Organisation. Geben Sie diese Option mehrmals an, um mehreren Besitzern zu entsprechen.
-P <program>	Berücksichtigen Sie nur Vorgänge, bei denen ein bestimmtes Git-Unterprogramm ausgeführt wurde, wie upload-pack, receive-pack, rev-list oder pack-objects. Geben Sie diese Option mehrmals an, um mehreren Programmen zu entsprechen.
-I <address>	Erwägen Sie nur Vorgänge aus einer bestimmten IP-Adresse. Geben Sie diese Option mehrmals an, um mehrere Adressen abzugleichen.

Ausgabeoptionen

Option	Description
-j	Legen Sie das Ausgabeformat auf JSON anstelle einer ASCII-Tabelle fest.
-n <N>	Beschränken Sie die Ausgabe auf N-Datensätze. Der Standardwert ist 20 für aggregierte Abfragen und 200 für top-Abfragen.
--count-only	Nur die KEY``COUNT Spalten anzeigen. Gilt nur für aggregierte Abfragen.

Interpretieren von Ergebnisspalten

Die folgenden Abkürzungen werden in ghe-governor Ergebnistabellen angezeigt.

Column	Bedeutung
AVG RT	Durchschnittliche Zeit in Sekunden, die für Git-Aufrufe benötigt wurde
MAX RT	Laufzeit in Sekunden des längsten Aufrufs pro Host
MAXPL / AVGPL	Maximale und durchschnittliche Parallelität: wie viele Git-Aufrufe gleichzeitig offen waren
CPU/SEC	Sekunden der CPU-Zeit, die von Git pro Sekunde der Wanduhrzeit verwendet wird. Dividieren Sie die Anzahl der CPU-Kerne, und multiplizieren Sie sie mit 100, um den gitspezifischen CPU-Prozentsatz zu erhalten. Dieser Wert darf die Anzahl der CPU-Kerne nicht überschreiten.
UPL	Daten, die der Server auf Clients hochgeladen hat, z. B. während der Abrufe und Klonen
RECV	Daten, die der Server von Clients empfangen hat, z. B. während pushes

Die READSpalten , WRITEund UPLdie RECV Spalten werden in Gigabyte (GB) gemeldet, und die entsprechende Rate wird in Megabyte pro Sekunde (MB/s) gemeldet.

Gängige Muster interpretieren

Die folgende Tabelle ordnet allgemeine Ausgabemuster von Gouverneuren ihren wahrscheinlichen Ursachen zu.

Pattern	Wahrscheinliche Ursache
Hohe upload-pack Anzahl aus einer kleinen Gruppe von IP-Adressen	Eine CI-Runner-Flotte klont wiederholt ein oder mehrere Repositories, anstatt lokale Checkouts wiederzuverwenden
Hoch max_parallelism für eine kleine Anzahl von Repositorys	Thundering herd: viele Runner lösen gleichzeitig Klonvorgänge aus, oft weil geplante Jobs gleichzeitig starten
Große uploaded_kb pro Repository kombiniert mit hohen avg_uploaded pro Benutzer	Wiederholte vollständige Klonvorgänge; Clients verwenden lokale Checkouts nicht wieder oder verwenden keine flachen oder partiellen Klone
Hoch received_kb für ein Repository oder eine Organisation	Push-intensive Arbeitslast; kann große Binärdateien oder häufige Commits in einem Monorepo umfassen
Hohe pack-objects CPU bei moderater Anzahl an Operationen	Aufwendiges Objektpacken; das Repository kann von einem Wartungslauf oder von der clientseitigen Nutzung partieller Klone mit --filter profitieren
Hoch avg_rt oder max_rt für ein Repository	Langsame Vorgänge; häufig verursacht durch umfangreiche pack-objects-Ausführungen, hohe Parallelität oder Ressourcenkonflikte durch eine andere Workload

Empfohlene Maßnahmen zur Reduzierung der Git-Last

Wenn Governor-Daten zeigen, dass ein Repository, ein Benutzer oder eine Runner-Flotte eine übermäßige Last verursacht, können die folgenden Maßnahmen die Auswirkungen verringern.

• Lokale Auscheckvorgänge wiederverwenden. Ersetzen Sie frische Klone in automatisierten Workflows durch git fetch. Dadurch wird die Übertragung des vollständigen Objektdiagramms bei jeder Ausführung vermieden.
• Verwenden Sie flache Klone. Für Workflows, die keinen vollständigen Commit-Verlauf erfordern, übergeben Sie --depth an den Clone-Befehl, zum Beispiel git clone --depth 1. Dies reduziert sowohl die übertragenen Daten als auch den Arbeitsaufwand, den pack-objects leisten muss.
• Verwenden Sie partielle Klone. Verwenden Sie --filter für Repositorys mit großen binärobjekten oder vielen Dateien, die in einem bestimmten Workflow nicht benötigt werden, um nur die Objekte anzufordern, die der Workflow benötigt, z git clone --filter=blob:none. B. . .
• Fügen Sie einen lokalen Spiegel- oder Zwischenspeicherungsproxy hinzu. Bei großen Runner-Flotten, die wiederholt dieselben Repositorys klonen, kann ein Pull-through-Proxy oder ein lokales Spiegel-Repository den Fetch-Datenverkehr abfangen und die Last auf Ihrer Instanz verringern.
• Staffeln Sie geplante Aufträge zeitlich. CI/CD-Workflows sollten zeitlich versetzt nach einem Zeitplan ausgeführt werden, sodass nicht alle Runner gleichzeitig starten und so die Anzahl gleichzeitiger Klonvorgänge reduziert wird.
• Reduzieren Sie die Workflow-Parallelität. Workflows, die mehrere Repositorys parallel klonen, können so konfiguriert werden, dass die Parallelität begrenzt und die Last im Laufe der Zeit verteilt wird.

Wann wenden Sie sich an GitHub den Support?

Wenden Sie sich an GitHub Enterprise-Support und fügen Sie ein Support-Bundle bei, wenn einer der folgenden Punkte zutrifft.

• Die Leistung bleibt auch nach der Reduzierung der Klonlast oder dem zeitversetzten Ausführen geplanter Aufträge beeinträchtigt.
• Ihre Instanz verursacht zahlreiche Git-Fehler oder Verbindungsausfälle, die nicht durch die Client-Auslastung erklärbar sind.
• Governor zeigt anhaltend hohe max_parallelism-Werte, was darauf hindeutet, dass die Instanz an oder nahe ihrer Kapazitätsgrenze arbeitet und sich das Problem allein durch Änderungen der Workload voraussichtlich nicht beheben lässt.
• Sie sehen ein klares Muster in der Governor-Ausgabe, sind sich aber unsicher, wie es zu interpretieren ist oder welche Maßnahmen Sie ergreifen sollen.

Weitere Informationen zum Generieren eines Supportpakets finden Sie unter Bereitstellen von Daten für GitHub Support.

Weiterführende Lektüre

Weitere Informationen zur Überwachung von Systemressourcen finden Sie unter Informationen zu den Monitordashboards.