Datenträgerauslastung an oder nahe der Kapazitätsgrenze

Warnung

Entfernen Sie nur die in diesem Artikel beschriebenen Dateien. Das Löschen anderer Elemente kann zu Datenverlusten führen oder Ihre GitHub Enterprise Server-Instance unbrauchbar machen. Das Erhöhen der Größe eines Datenträgers erfordert Ausfallzeiten. Planen Sie also ein Wartungsfenster, bevor Sie beginnen.

Symptome

GitHub Enterprise Server speichert Daten auf zwei Datenträgern: dem Root-Datenträger, eingehängt unter /, und dem Datenträger, eingehängt unter /data/user. Wenn einer der beiden Datenträger voll ist, können Dienste nicht mehr darauf schreiben, und möglicherweise wird einer der folgenden Hinweise angezeigt.

Die Webschnittstelle gibt 500 Fehler zurück.
git push Vorgänge schlagen fehl.
Dienste können nicht gestartet werden oder nach einem Neustart nicht mehr reagieren.
Konfigurationsausführungen schlagen fehl, auch die, die ausgelöst werden, wenn Sie Einstellungen in der Verwaltungskonsole speichern oder ein Upgrade der Instanz durchführen. Weitere Informationen findest du unter Befehlszeilenwerkzeuge.

Elasticsearch reagiert auch auf die Datenträgernutzung, bevor der Datenträger voll ist. Sobald die Auslastung 85% erreicht hat, kann Elasticsearch Shards nicht mehr zuweisen und der Clusterstatus wird rot. Ein roter Cluster blockiert Konfigurationsläufe, was wiederum Upgrades sowie das Starten oder Stoppen der Replikation auf einem Replikat blockiert. Halten Sie die Datenträgernutzung unter 85 %, und benachrichtigen Sie deutlich vor diesem Punkt, wobei 60 % als Warnung und 75 % als kritisch gelten. Weitere Informationen findest du unter Empfohlene Schwellenwerte für Meldungen.

Ursachen

Der Root-Datenträger füllt sich, wenn sich Dateien, die vom Betriebssystem und von GitHub Enterprise Server Diensten geschrieben werden, schneller ansammeln, als sie gelöscht werden. Die häufigsten Ursachen sind schnell wachsende Protokolldateien (einschließlich rotierter Protokolle) und Upgradepakete, die von automatischen Updateüberprüfungen heruntergeladen oder an dem Ort gespeichert wurden, an den sie manuell heruntergeladen wurden, z. B. /home/admin/.

Der Datenträger füllt sich, wenn Repository-, Paket- und GitHub Actions-Daten über die von Ihnen bereitgestellte Kapazität hinaus wachsen.

Wenn GitHub Actions diese Option aktiviert ist, sind MSSQL-Transaktionsprotokolle eine häufige Ursache für das Auffüllen des Datenträgers. In einer Hochverfügbarkeitskonfiguration werden die Datenbanken im vollständigen Wiederherstellungsmodell ausgeführt, was die Replikation erfordert, sodass der Protokollspeicher nur wiederverwendbar gemacht wird, wenn eine Sicherung ausgeführt wird. Wenn Sicherungen nicht häufig genug ausgeführt werden oder fehlschlagen, erweitern sich die Protokolle so lange, bis sie den Datenträger füllen oder bis ein Protokoll den Grenzwert von 2 TB pro Datei erreicht, wodurch sich Runner ebenfalls nicht mehr registrieren können.

Bestätigung des Problems

Per SSH mit der administrativen Shell verbinden. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
Überprüfen Sie, wie viel Speicherplatz auf jedem lokalen Datenträger verwendet wird.
```
df -h -t ext4
```
Lesen Sie die Use% Spalte für die Zeile, die unter / eingehängt ist, also den Root-Datenträger, und die Zeile, die unter /data/user eingehängt ist, also den Datenträger.
```
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              98G   93G  1.1G  99% /
/dev/mapper/ghe_user  251G   50G  189G  21% /data/user
```
Wenn beide Datenträger freien Speicherplatz melden, dienste jedoch immer noch nicht schreiben können, überprüfen Sie die Inode-Verwendung. Ein Datenträger mit freiem Speicherplatz kann dennoch keine freien Inodes mehr haben.
```
df -i -t ext4
```
Identifizieren Sie, was Speicherplatz belegt, und wo es Möglichkeiten gibt, Speicherplatz freizugeben. Dies berichtet sowohl über die Root-Datenträger als auch über die Datenträger.
```
ghe-check-disk-usage
```

Beheben des Problems

Arbeiten Sie mit der ghe-check-disk-usage Ausgabe. Das Freigeben von Speicherplatz ist schneller als das Ändern der Größe und benötigt keine Ausfallzeiten. Versuchen Sie es also zuerst, wenn die Ausgabe Ihnen konkrete Hinweise zum Handeln liefert. Wenn dies nicht der Fall ist, benötigt die Instanz mehr Speicher.

Freigeben von Speicherplatz auf dem Root-Datenträger

Wenn unter /var/lib/ghe-updates Upgradepakete aufgeführt sind, entfernen Sie alle für eine Version, die Sie bereits installiert haben oder nicht installieren möchten. Jedes Paket ist mehrere Gigabyte groß. Ersetzen Sie PACKAGE durch den Dateinamen.
```
sudo rm /var/lib/ghe-updates/PACKAGE
```
Wenn in der Ausgabe Upgradepakete unter /home/admin oder an einem anderen Ort aufgeführt sind, an den Sie sie manuell heruntergeladen haben, entfernen Sie alle, die Sie bereits installiert haben oder nicht mehr benötigen. Ersetzen Sie PACKAGE durch den Pfad zu jedem einzelnen.
```
sudo rm PACKAGE
```
Wenn in der Ausgabe große Protokolldateien unter /var/log aufgeführt sind, die auf .1 oder .gz enden, entfernen Sie sie. Diese wurden bereits rotiert und in diese wird nicht mehr geschrieben. Ersetzen Sie LOG-FILE durch den jeweiligen Pfad.
```
sudo rm LOG-FILE
```
Warnung

Behandeln Sie dies als Notfallmaßnahme, um Platz schnell frei zu geben. Dadurch wird nicht behoben, was auch immer das Protokollvolumen erzeugt. Wenn dies fortgesetzt wird, werden die rotierten Protokolle wieder auftreten, und der Datenträger läuft wieder voll. Wenn nach dem Entfernen wieder Speicherplatz verbraucht wird, wenden Sie sich an GitHub-Support anstatt diesen Schritt zu wiederholen.
Vergewissern Sie sich, dass der Speicherplatz freigegeben wurde.
```
df -h /
```

Wiedergewinnen von Speicherplatz auf dem Datendatenträger

Dies gilt nur, wenn GitHub Actions aktiviert ist, da MSSQL nur in diesem Fall ausgeführt wird.

Überprüfen Sie die MSSQL-Transaktionsprotokollanalyse in der ghe-check-disk-usage Ausgabe, in der die Dateien aufgelistet sind, die auf .ldf enden, unter /data/user/mssql/data aufgeführt werden und die ungewöhnlich groß sind, gekennzeichnet werden. Diese Protokolle wachsen, wenn Sicherungen nicht häufig genug ausgeführt werden, um Speicherplatz freizugeben, und es handelt sich um eine häufige Ursache für einen vollen Datenträger.

Wenn die Ausgabe große Transaktionsprotokolle kennzeichnet, lesen Sie Kürzen von MSSQL-Transaktionsprotokollen, um die Ursache zu bestätigen und sie zu kürzen.

Speicherkapazität erhöhen

Wenn ghe-check-disk-usage rotierte Protokolldateien, Upgradepakete, alte Dateien unter /data/user/tmp oder überdimensionierte MSSQL-Transaktionsprotokolle nicht identifiziert hat, kann nichts sicher freigegeben werden, und die Instanz benötigt mehr Speicher. Dies gilt auch, wenn die Nutzung kurz nach dem Freigeben des Speicherplatzes wieder auf dasselbe Niveau zurückkehrt.

Vergrößern Sie die Größe des Stamm- oder Datenträgers gemäß Speicherkapazität erhöhen.

Erneutes Auftreten verhindern

Wenn die Auslastung einmal die Kapazitätsgrenze erreicht hat, tritt dies in der Regel erneut auf, daher überwachen Sie beide Datenträger und reagieren Sie, bevor sie voll sind.

Warnung bei der Root- und Datenträgerauslastung, sodass Sie Zeit haben, zu reagieren, bevor einer der beiden Datenträger gefüllt wird.
Überprüfen Sie, wie viel Speicherplatz Ihr tatsächlicher Bedarf tatsächlich benötigt, anstatt die Größe auf das Minimum zu ändern. Weitere Informationen findest du unter Problembehandlung von Ressourcenzuweisungsproblemen.
Verringern Sie das Protokollvolumen an der Quelle, sodass rotierte Protokolle den Root-Datenträger nicht erneut ausfüllen. Clients, die die REST-API abfragen, generieren häufig große Mengen von Protokolldaten, und Webhooks sind eine effizientere Alternative. Weitere Informationen findest du unter Informationen zu Webhooks.
Wenn GitHub Actions diese Option aktiviert ist, führen Sie Sicherungen nach einem Zeitplan aus, und überprüfen Sie, ob sie abgeschlossen sind, sodass MSSQL-Transaktionsprotokolle nicht unkontrolliert anwachsen. Weitere Informationen findest du unter Konfigurieren des Sicherungsdiensts.

Kontaktieren GitHub-Support

Wenn das Problem durch diese Schritte nicht behoben wird oder Sie sich bei einem dieser Schritte nicht sicher sind, wenden Sie sich an GitHub-Support, anstatt fortzufahren. Weitere Informationen findest du unter Erstellen eines Supporttickets.

Wenn Sie bereits ein Ticket geöffnet haben, hilft GitHub-Support das Anfügen eines Support-Bundles, das Problem schneller zu diagnostizieren. Weitere Informationen findest du unter Bereitstellen von Daten für GitHub Support.

Hinweis

Supportbundle werden standardmäßig auf die Datenfestplatte geschrieben. Wenn die Datenfestplatte voll ist, schlägt die Generierung einer solchen möglicherweise fehl.