Wie viel Speicher-Overhead fügt Immich zusätzlich zu den Quelldaten hinzu?

Immich fügt keinen universellen Prozentsatz für den Speicherbedarf hinzu; der Overhead hängt hauptsächlich von der Anzahl der Assets, dem Videoanteil, den Einstellungen für abgeleitete Dateien, dem Datenbankwachstum und den aufbewahrten Backups ab.

Eine ein Terabyte große Familienbibliothek, die überwiegend aus Fotos besteht, wird nicht einer Bibliothek ähneln, die überwiegend aus langen Handyvideos besteht. Plane den Speicher, indem du jede erzeugte Kategorie nach einem repräsentativen Import misst und anschließend separate Reserven für Wachstum, temporäre Arbeitsdaten und Wiederherstellungskopien einplanst.

Abgeleitete Medien bilden meist den größten sichtbaren Overhead

Immich erstellt kleinere Bilder für Zeitleisten und die Anzeige und kann kodierte Versionen von Videos für eine kompatible Wiedergabe erzeugen. Diese Ausgaben skalieren mit der Anzahl der Assets, der Auflösung, den Qualitätseinstellungen sowie der Länge und dem Codec-Mix der Videos. Sie kommen zu den Originaldateien hinzu, auch wenn Nutzer sie nie direkt herunterladen.

Eine Messung aus der Community einer 772 GiB großen externen Bibliothek ergab etwa 18 GiB Vorschaubilder und 65 GiB kodierte Videos. Diese Beobachtung von ungefähr 83 GiB ist ein nützliches Rechenbeispiel, aber keine Planungsquote, da der Foto-Video-Mix und die Einstellungen einer anderen Bibliothek beide Komponenten erheblich verändern können.

Erfasse die Verzeichnisse für Vorschaubilder und kodierte Videos nach dem Import eines repräsentativen Ausschnitts, der die tatsächlichen Fotos, RAW-Dateien, kurzen Clips und langen Videos des Haushalts enthält. Teile jede Kategorie der abgeleiteten Dateien separat durch die Anzahl der Assets und die Größe der Quelldateien. Assetbasierte und bytebasierte Quoten beantworten unterschiedliche Fragen zum Wachstum.

Datenbank und Suchstatus skalieren mit den Beziehungen

Der Datenbank-Overhead entsteht durch Asset-Datensätze, Nutzer, Alben, Metadaten, Gesichter, Suchrepräsentationen, Indizes und den Status von Aufgaben. Ein kleines Bild und ein großes Video können bei einigen Datensätzen ähnliche Anzahlen erzeugen, obwohl ihre Quelldateien sehr unterschiedlich groß sind. Dadurch hängt das Datenbankwachstum stärker von Entitäten und aktivierten Funktionen ab als von den ursprünglichen Terabytes.

Der Immich-Backup-Artikel von ZimaSpace trennt wichtige Originale und den Datenbankstatus von abgeleiteten Pfaden, die möglicherweise neu erstellt werden können. Diese Trennung ist für die Prognose wichtig, denn das Löschen abgeleiteter Dateien kann zwar vorübergehend Speicher freigeben, der Verlust der Datenbank verändert jedoch Beziehungen, die Vorschaubilder nicht wiederherstellen können.

Erfasse die Datenbankgröße vor und nach dem Import einer bekannten Gruppe und notiere, welche Verarbeitungsfunktionen abgeschlossen wurden. Wiederhole die Messung, nachdem die Arbeiten für Gesichter und Suche beendet sind. Extrapoliere nicht aus einer noch nicht abgearbeiteten Warteschlange, da der scheinbare Overhead pro Asset steigt, sobald zusätzliche Repräsentationen und Beziehungen geschrieben werden.

Backups und temporäre Arbeiten verändern die erforderliche Mindestkapazität

Eine laufende Gesamtsumme berücksichtigt nicht den Speicher, der während der Erstellung von Backups, dem Export von Datenbanken, der Vorbereitung von Importen oder dem Ersetzen abgeleiteter Dateien benötigt wird. Während eines Upgrades oder einer Neugenerierung können alte und neue Dateien gleichzeitig vorhanden sein. Ein Datenträger, der exakt auf den stabilen Betriebsbedarf ausgelegt ist, kann daher bei gewöhnlichen Wartungsarbeiten ausfallen, selbst wenn das jährliche Medienwachstum gering ist.

Ein Aufsatz zur Speicherplanung beschreibt, wie Immich eine zuvor freie SSD durch Originale, Vorschaubilder, Metadaten und Machine-Learning-Arbeiten füllte. Die übergeordnete Erkenntnis lautet, dass Anwendungswachstum und Wiederherstellungskopien mit dem betrieblichen Spielraum konkurrieren. Eine Angabe zum freien Speicher muss daher die ausgelastetste Wartungssituation abdecken und nicht nur den heutigen Leerlaufzustand.

Führe die Aufbewahrung von Backups als separaten Posten, da Kopien außerhalb des Hosts vor einem anderen Ausfall schützen. Reserviere außerdem einen anhand des größten Imports, der größten Neukodierung oder des größten Upgrade-Tests ermittelten Arbeitsbereich. Mehr ungenutzter Speicher ist nicht automatisch besser, aber eine gemessene Spitzenreserve von null macht einen Kapazitätsausfall vorhersehbar.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Erstelle ein bibliotheksspezifisches Arbeitsblatt für den Overhead

Erstelle Zeilen für Originale, Vorschaubilder und Vorschauen, kodierte Videos, die Datenbank, Machine-Learning-Artefakte, lokale Backup-Exporte und den temporären Spitzenbedarf. Miss zunächst eine leere Ausgangsbasis und importiere anschließend eine repräsentative Gruppe. Warte, bis die Warteschlangen abgearbeitet sind, und erfasse jede Zeile erneut, bevor du die Differenzen berechnest.

Eine Diskussion unter Anwendern über die Platzierung auf SSD und HDD unterscheidet zwischen erzeugten Daten, bei denen die Latenz wichtig ist, und umfangreichen Originaldateien. Für die Kapazitätsplanung sorgt diese Unterscheidung dafür, dass der Overhead der schnellen Speicherebene sichtbar bleibt, selbst wenn die Originale an einem anderen Ort liegen. Andernfalls kann die große NAS-Gesamtsumme eine fast volle Anwendungs-SSD verbergen.

Wiederhole die Gruppe einmal, um statt einer einzigen Quote einen Bereich zu erhalten. Prognostiziere jede Zeile anhand des passenden Treibers: Assetanzahl, Videobytes oder -dauer, Wachstum von Nutzern und Beziehungen, Anzahl der aufbewahrten Kopien oder Spitzenbedarf während Wartungsarbeiten. Füge das geplante Wachstum der Quelldateien erst hinzu, nachdem der Bedarf für abgeleitete Daten und Wiederherstellung separat sichtbar geworden ist.