Warum wachsen der Speicherplatz für Immich-Miniaturansichten und ML-Daten bei großen Importen vom Mobilgerät?

Große Importe erweitern den Immich-Speicher in der Regel, weil jedes Asset abgeleitete Dateien und Datenbankeinträge erzeugt, während heruntergeladene Modelle einen separaten Cache belegen.

Eine Familie verschiebt jahrelange Handyfotos auf ein Heim-NAS und beobachtet, wie der freie Speicher weiter abnimmt, nachdem der Upload-Zähler bereits fertig ist. Das kann auf legitime Hintergrundverarbeitung und nicht auf eine weitere Kopie jedes Originals hindeuten. Entscheidend ist die Unterscheidung zwischen pro Asset erzeugten Dateien, gemeinsam genutzten Modelldateien und Wachstum, das ohne entsprechende Zunahme abgeschlossener Aufgaben anhält.

Ein Upload erzeugt mehrere Arten von Zuständen

Das hochgeladene Original ist nur ein Teil der resultierenden Bibliothek. Immich erstellt außerdem kleinere Darstellungen zum Durchsuchen und speichert Informationen, die das Asset mit seinem Besitzer, Datumsangaben, Alben und Suchfunktionen verknüpfen. Diese Ausgaben bedienen unterschiedliche Anfragen. Daher bedeutet der Abschluss der Netzwerkübertragung nicht, dass bereits jeder nachgelagerte Schreibvorgang abgeschlossen ist.

Die Trennung zwischen Mediendateien und Datenbankeinträgen ist hier wichtig: Anwendungsmetadaten und Such-Embeddings liegen in PostgreSQL und sind keine zusätzlichen Fotos in voller Auflösung. Der Dienst für maschinelles Lernen berechnet Ergebnisse, die von der Anwendung verwendet werden. Alle zusätzlichen Bytes als duplizierte Originale zu betrachten, liefert daher für das normale Wachstum durch Importe die falsche Erklärung.

Stell dir vor, ein Handy beendet die Übertragung, während der Server das übernommene Paket noch verarbeitet. Die Originale können bereits dauerhaft auf der Festplatte liegen, während weiterhin Vorschauen und durchsuchbare Einträge entstehen. Vergleiche Speichermessungen in derselben Verarbeitungsphase; ein gerade hochgeladenes Kontingent und ein vollständig verarbeitetes Kontingent sind keine gleichwertigen Stichproben.

Die Anzahl der Assets erklärt mehr als die Gigabyte der Originale

Bei der Planung des Thumbnail-Speichers erklärt die Anzahl und Art der Assets oft mehr als die Gesamtgröße der Originale in Gigabyte. Tausend kleine Fotos und eine Handvoll langer Videos können ähnlich viel Ausgangsspeicher belegen, aber eine sehr unterschiedliche Anzahl an Bildableitungen erfordern. Vorschauabmessungen, Kompressionseinstellungen und Bildinhalte verändern die erzeugte Datenmenge zusätzlich.

Veröffentlichte Messungen zum Thumbnail-Speicher veranschaulichen diese Unterschiede: Ein Besitzer berichtete von 6,3 GB bei einer 70-GB-Bibliothek, während ein anderer etwa 370 GB bei 2 TB Fotos und Videos angab. Das sind individuelle Konfigurationen und keine vergleichbaren kontrollierten Benchmarks. Sie zeigen, warum die Übernahme eines einzelnen Prozentsatzes aus einem Forum einen anderen Haushalt falsch darstellen kann.

Als Beispielrechnung benötigen 100.000 Assets mit durchschnittlich 250 KB gemessenen Bildableitungen etwa 25 GB in Dezimaleinheiten. Bei jeweils 500 KB benötigt dieselbe Anzahl etwa 50 GB. Beide Werte enthalten weder Originale noch kodierte Videos, Datenbankwachstum oder Sicherungskopien; das Beispiel isoliert das Verhältnis pro Asset, statt einen universellen Aufschlag zu empfehlen.

Modelldateien und Sucheinträge wachsen unterschiedlich

Der Modell-Cache enthält wiederverwendbare Modelldateien, während Suchvektoren einzelne Assets repräsentieren. Bei einem festen Satz heruntergeladener Modelle müssen beim Hinzufügen weiterer Fotos nicht für jedes Bild erneut vollständige Modelle heruntergeladen werden. Das Hinzufügen oder Ändern von Modellen kann den Cache-Speicher stattdessen schrittweise und unabhängig von der Anzahl hochgeladener Fotos vergrößern.

Eine portable Bereitstellung aus der Praxis hält die Bibliothek, den Modell-Cache und die PostgreSQL-Daten in separaten persistenten Verzeichnissen. Diese Trennung macht jede Speicherrolle sichtbar, ohne anzunehmen, dass eine gemeinsame Docker-Größe die Ausgabe des maschinellen Lernens repräsentiert. Es handelt sich um ein Layout-Beispiel aus einer älteren Version, nicht um eine aktuelle Installationsanleitung oder eine empfohlene Auswahl von Container-Tags.

Unterscheide außerdem zwischen Festplattennutzung und belegtem Arbeitsspeicher. Ein Modell kann auf der Festplatte verbleiben, während seine Kopie im Arbeitsspeicher entladen wird, und der Dateisystem-Cache kann den gemeldeten Speicherverbrauch erhöhen, ohne weitere dauerhafte Dateien zu erzeugen. Um einen Anstieg zu erklären, ermittle zuerst das zuständige Verzeichnis und die geänderte Einstellung, bevor du aus einem Containernamen Schlussfolgerungen ziehst.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wann normales Wachstum keine ausreichende Erklärung mehr ist

Das normale Wachstum durch Ableitungen hat eine begrenzte Grundlage: ein festes Kontingent an Originalen, das mit unveränderten Einstellungen verarbeitet wird. Es sollte keine endlos wachsende Population neuer Quell-Assets erzeugen. Wenn die Asset-Anzahl weiter steigt, nachdem alle vorgesehenen Importe beendet wurden, muss die Erklärung Erkennungspfade, wiederholte Aufnahme oder eine andere Quelle neuer Aufgaben berücksichtigen.

Ein bestätigter Fall von rekursivem Scannen umfasste den Immich-Upload-Speicherort innerhalb einer externen Bibliothek. Die erzeugten Thumbnails wurden anschließend als neue Bilder behandelt, wodurch weitere Ableitungen von Ableitungen entstanden. Das ist ein anderer Kausalmechanismus als ein großer Mobil-Upload und darf nicht als Beleg dafür dienen, dass jede umfangreiche Bibliothek sich natürlicherweise unbegrenzt vervielfacht.

Ungewöhnliches Wachstum in einer beschreibbaren Container-Schicht ist eine weitere eigenständige Kategorie. Ein Bericht aus dem Jahr 2026 beschrieb, dass sich dort Hunderte Gigabyte ansammelten; die Diskussion stellte jedoch keine allgemeingültige Ursache fest. Lösche keine Datenbankdateien, Medien oder Docker-internen Daten, nur damit eine Grafik normal aussieht. Stelle zunächst fest, welche Rolle wächst und ob abgeschlossene Aufgaben dies erklären.

Miss den Import nach Speicherrollen

Erfasse vor einem repräsentativen Import die Anzahl und Byte-Größe der Original-Assets, die Größe von Thumbnails und Vorschauen, die Größe kodierter Videos, die Datenbankgröße, die Größe des Modell-Caches sowie jegliches Wachstum durch temporäre Dateien oder Protokolle. Wiederhole die Messung, nachdem dasselbe Kontingent alle aktivierten Verarbeitungsaufgaben abgeschlossen hat. Lass die Medieneinstellungen unverändert, damit Unterschiede dem Import und nicht einer gleichzeitig vorgenommenen Konfigurationsänderung zugeschrieben werden können.

Die Speicherbilanz ersetzt keinen Sicherungsplan für die Familie. Ein nutzbarer Fotodienst benötigt geschützte Originale und den Anwendungszustand, der zur Wiederherstellung der Bibliothek erforderlich ist; ein Thumbnail-Verzeichnis allein kann die Familiensammlung nicht bewahren. Halte diese Schutzmaßnahme von der Messung regenerierbarer Zusatzdaten getrennt, damit ein Experiment zur Speicherersparnis nicht zur einzigen Kopie einer Erinnerung wird.

Akzeptiere das Ergebnis, wenn die gemessenen Summen der einzelnen Rollen die hinzugekommenen Bytes erklären und keine unerwarteten Quell-Assets weiter auftauchen. Untersuche einen anderen Mechanismus, wenn sich das Modellinventar nicht verändert, aber das Wachstum des Caches oder der beschreibbaren Schicht anhält oder wenn abgeleitete Dateien erneut in die Erkennung gelangen. Dieser Test beantwortet, warum der Speicher gewachsen ist, ohne aus einer Erklärung ein destruktives Bereinigungsverfahren zu machen.