Wiki

Speicher & GC

Speicher-Dashboard pro Repository (Größe, Deduplizierung, Wachstum) und Garbage Collection: Bereinigung alter Revisionen, verwaister chunks, phantom files.

Einführung

Der Reiter Speicher zeigt die Festplattenbelegung eines Repositorys und bietet ein Garbage-Collection-Werkzeug (GC), um Platz zurückzugewinnen, indem alte Revisionen und nutzlos gewordene Daten bereinigt werden.

Zugriff und Rollen

Verfügbar für den Super-Admin und für einen project_admin auf den von ihm verwalteten Repositorys, einschließlich des Startens von GC. Die globalen Serverstatistiken und die Lizenz hingegen sind dem Super-Admin vorbehalten (an anderer Stelle im Panel).

Die Metriken

Das Speicher-Dashboard: Deduplizierungsrate, 30-Tage-Wachstumshistogramm und die Top 20 der größten Dateien.

Gesamtgröße und komprimierte Größe.
Deduplizierungsrate (%): der durch chunk-Sharing und Kompression eingesparte Anteil an Speicherplatz.
Dateien / Revisionen / chunks.
Wachstum (letzte 30 Tage): ein Histogramm der Revisionen pro Tag.
Größte Dateien: die Top 20 nach Größe, mit ihrer Anzahl an Revisionen.

Diese Zahlen helfen, ein aufgeblähtes Repository zu erkennen: eine große, immer wieder neu committete Binärdatei oder ein ungewöhnliches Wachstum über die letzten 30 Tage.

Garbage Collection

Das GC-Panel: Felder für Aufbewahrung und Min-Revisionen, Schaltflächen Preview und Run GC sowie ein Ergebnisbanner.

GC bereinigt die alte Historie anhand zweier Parameter:

Parameter	Standard	Rolle
Retention (days)	90	Alter, unterhalb dessen eine Revision immer erhalten bleibt.
Min revisions to keep	5	Anzahl der pro Datei erhaltenen jüngsten Revisionen, unabhängig von ihrem Alter.

Zwei Schaltflächen:

Preview: simuliert, ohne etwas zu löschen. Banner: „X Revisionen würden über Y Dateien hinweg gelöscht, Z phantom-Einträge (Geistereinträge) würden entfernt“. Immer zuerst eine Vorschau.
Run GC: führt es tatsächlich aus. Banner: „X Revisionen gelöscht, Y verwaiste chunks bereinigt, Z phantom-Einträge entfernt“. Der Lauf wird im Audit-Log protokolliert.

GC ist destruktiv und unumkehrbar Bereinigte Revisionen (jenseits des Aufbewahrungsfensters) lassen sich nicht wiederherstellen. Führe eine Preview vor jedem Run GC aus und prüfe, dass die Zahlen deinen Erwartungen entsprechen.

Was GC löscht

Alte Revisionen: solche, die älter als Retention (days) sind UND über die Min revisions to keep jüngsten je Datei hinausgehen. Anschließend deren chunks, sofern sie von keiner anderen Revision mehr referenziert werden.
Verwaiste chunks: Datenblöcke, die nach der Bereinigung von keiner Revision mehr genutzt werden.
Phantom files: Dateizeilen, die nie wirklich committet wurden (ungültiger Pfad oder ein hängen gebliebener Eintrag), jenseits eines festen 7-Tage-Fensters (nicht konfigurierbar).

Die Löschmarkierungen (tombstones) gelöschter oder obliterierter Dateien werden verschont: sie dienen dazu, die Löschung beim Sync an die Clients zu propagieren, und dürfen daher nicht verschwinden.

Häufige Fallstricke

Preview meldet nur sehr wenig

Normal, wenn das Repository neu ist oder die Historie innerhalb des Aufbewahrungsfensters liegt. GC berührt nur Revisionen, die zugleich alt genug und jenseits der letzten N je Datei sind.

Preview und Run zeigen unterschiedliche Zähler

Preview kann die genaue Zahl der gelöschten chunks und Revision-chunk-Verknüpfungen nicht vorhersagen: es meldet nur Revisionen, gescannte Dateien und phantom-Einträge. Verwaiste chunks erscheinen erst beim Run.

Aufbewahrung senken, um Platz zurückzugewinnen

Möglich, aber du verlierst Historie. Bei einem Projekt, in dem man weit zurückgehen können muss, behalte eine großzügige Aufbewahrung bei und setze stattdessen bei den großen Dateien an (siehe die Liste der größten Dateien und die .uversionignore, um das Tracking regenerierbarer Artefakte zu vermeiden).