Wie viel RAM und Speicherplatz braucht Immich?

Wie viel RAM benötigt Immich?

Immich setzt 6 GB RAM (Arbeitsspeicher) als dokumentiertes Minimum und 8 GB als Empfehlung voraus, bei 2 CPU-Kernen für den Einstieg und 4 für eine komfortable Installation. Dieser Wert deckt den gesamten Stack ab, da Immich aus vier Containern besteht und nicht nur aus einer einzelnen Anwendung. Das Durchsuchen einer bereits importierten Mediathek ist ressourcenschonend. Der Speicherbedarf entsteht beim Importieren, wobei der Großteil auf einen Container entfällt, den Sie bei Bedarf deaktivieren können.

[
  {
    "label": "Documented minimum",
    "ram_gb": 6,
    "cpu_cores": 2
  },
  {
    "label": "Documented recommended",
    "ram_gb": 8,
    "cpu_cores": 4
  }
]

Dies sind die veröffentlichten Werte von der Immich-Anforderungsseite mit Stand Oktober 2026. Es handelt sich um eine Empfehlung zur Dimensionierung, nicht um eine Prüfung, die beim Start der Software erfolgt. Dieselbe Seite dokumentiert ein kleineres Setup mit 4 GB bei deaktivierten Machine-Learning-Funktionen; darunter gibt es keine offiziellen Angaben. Auf einem kleineren Server ändert sich dadurch, welche Hintergrundprozesse abgeschlossen werden und wie sich ein Import verhält, wenn der Arbeitsspeicher erschöpft ist.

Es existiert ein echtes technisches Limit. Seit Version 3 benötigt der Machine-Learning-Container auf amd64-Hosts eine x86-64-v2-CPU, was die meisten seit etwa 2012 verkauften Prozessoren abdeckt. Die Anforderung gilt für diesen Container, nicht für den gesamten Server. Auf älterer Hardware können Sie daher das Machine Learning deaktivieren, es wie unten beschrieben auf einer anderen Maschine ausführen oder bei v2.7.5 bleiben, welche laut Immich-Dokumentation die letzte kompatible Version ist.

Falls die Installation noch vor Ihnen liegt, beginnen Sie mit der vollständigen Immich-Installation mit Docker Compose und kehren Sie anschließend hierher zurück, um die Dimensionierung des Servers vorzunehmen.

Wohin der Speicher geht: vier Container

Die offizielle Compose-Datei startet vier Dienste. Jeder hat ein anderes Speicherprofil. Eine einzige Gesamtsumme verdeckt daher die entscheidenden Details.

immich-server stellt die Weboberfläche und die API bereit und führt außerdem die Worker für Hintergrundaufgaben aus. Zwei Worker laufen in diesem einen Container. api verarbeitet die Anfragen des Browsers und der mobilen Anwendung. microservices verarbeitet die Warteschlangen, einschließlich der Thumbnail-Erstellung und der Videokodierung. Die Variablen IMMICH_WORKERS_INCLUDE und IMMICH_WORKERS_EXCLUDE teilen diese beiden Aufgaben auf separate Container auf. Dadurch können Sie der speicherintensiven Hälfte ein eigenes Speicherlimit geben, ohne den Teil zu begrenzen, der Ihre Fotos bereitstellt.

database ist ein PostgreSQL-14-Image mit integrierter VectorChord-Erweiterung. Es speichert alle Metadaten und einen Suchvektor pro Asset. In der Immich-Dokumentation wird für diesen Dienst die einzige ausdrückliche Mindestanforderung im Stack genannt: Wenn Sie Docker-Ressourcenlimits festlegen, benötigt die Datenbank mindestens 2 GB. Auf derselben Seite steht, dass die Datenbank idealerweise auf lokalem SSD-Speicher und niemals auf einer Netzwerkfreigabe beliebiger Art liegen sollte. Vektor- und Indexabfragen bestehen aus kleinen zufälligen Lesezugriffen. Ein Netzwerk-Volume macht daraus jeweils eine Round-Trip-Kommunikation. Wenn diese Frage für die Planung entscheidend ist, ist der Unterschied zwischen NVMe- und SATA-SSD-Speicher auf einem VPS hier wichtiger als bei jedem anderen Dienst in diesem Stack.

redis führt das Valkey-Image aus und speichert die Aufgabenwarteschlangen. Es ist mit großem Abstand der kleinste der vier Container, weil es Aufgabeneinträge statt Fotodaten speichert.

immich-machine-learning ist der Dienst, der die Größe Ihres Plans bestimmt. Er lädt Modelle für die intelligente Suche, die Gesichtserkennung und die Texterkennung. Ein geladenes Modell bleibt im Speicher. MACHINE_LEARNING_MODEL_TTL ist standardmäßig auf 300 gesetzt. Daher wird ein Modell nach fünf Minuten ohne Anfragen verworfen und bei der nächsten Anfrage aus dem /cache-Volume erneut eingelesen. Während eines Massenimports gibt es nie eine Lücke von fünf Minuten. Die Modelle bleiben deshalb vom ersten bis zum letzten Asset geladen.

Was sich während eines Imports ändert

Ein nicht ausgelastetes Immich arbeitet ruhig. Bei Imports können kleine Server jedoch ausfallen, weil das Hochladen eines Assets eine Kette von Jobs einreiht und mehrere Warteschlangen gleichzeitig verarbeitet werden.

Die Metadatenextraktion liest den Dateikopf und benötigt wenig Ressourcen. Die Thumbnail-Erzeugung ist aufwendiger. Immich erstellt pro Asset drei Thumbnail-Ausgaben: einen verschwommenen Thumbhash-Platzhalter, eine WebP-Vorschau und ein JPEG-Thumbnail. Zusätzlich wird für jedes erkannte Gesicht ein weiteres Thumbnail erstellt. Jeder dieser Jobs dekodiert ein Bild. Die Job-Konkurrenz legt fest, wie viele Bilder gleichzeitig dekodiert werden. Die Konkurrenz ist der Multiplikator, der aus den geringen Kosten eines einzelnen Jobs eine serverweite Belastung macht. Deshalb nennt die Immich-FAQ sie als erste Einstellung, die auf einem eingeschränkten System reduziert werden sollte. Setzen Sie die Konkurrenz für die aufwendigen Warteschlangen unter Administration, Settings, Job Settings auf 1.

Video-Assets erfordern zusätzlich Transkodierung. Jeder Transkodierungsjob ist ein eigener FFmpeg-Prozess mit eigenem Speicherbedarf. Er verwendet jeden CPU-Thread, den Sie ihm erlauben.

Smart Search sendet jedes neue Asset an den Machine-Learning-Container, um einen Embedding-Vektor zu berechnen. Die Gesichtserkennung führt über dasselbe Bild ein zweites Modell aus. Beim ersten Import einer vorhandenen Fotobibliothek werden beide Warteschlangen über jedes Asset verarbeitet, das Sie besitzen. Das dauert mehrere Stunden. Dies ist der Zeitpunkt mit der höchsten Speicherauslastung während der gesamten Installation. Er tritt einmalig auf.

Warum Gesichts- und Objekterkennung am meisten RAM benötigen

Die Gesichtsverarbeitung besteht aus zwei Aufgaben. Bei der Gesichtserkennung führt der Machine-Learning-Container ein Modell aus und ermittelt die Begrenzungsrahmen. Die Gesichtswiedererkennung ordnet diese Erkennungen anschließend Personen zu und fragt dafür den Vektorindex in Postgres ab. Eine große Bibliothek belastet daher beide Dienste nacheinander: zuerst den Modellcontainer während der Erkennung, anschließend die Datenbank während der Zuordnung.

Vier Einstellungen bestimmen, welche Daten der Machine-Learning-Container im Speicher hält.

• Das Gesichtsmodell. Immich wird standardmäßig mit buffalo_l ausgeliefert, und die FAQ empfiehlt buffalo_s für einen kleinen Server. Dieses Modell ist kleiner, benötigt daher weniger Speicher und läuft schneller. Dafür ist die Erkennungsgenauigkeit bei kleinen oder seitlich aufgenommenen Gesichtern geringer.
• Die Anzahl der Worker. MACHINE_LEARNING_WORKERS ist standardmäßig auf 1 gesetzt. Jeder Worker ist ein eigener Prozess und lädt eine eigene Kopie der Modelle. Eine Erhöhung auf 2 verdoppelt den belegten Modellspeicher daher ungefähr. Belassen Sie den Wert bei 1, sofern ausreichend RAM verfügbar ist.
• Die Batch-Größe. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION begrenzt, wie viele Gesichter gleichzeitig verarbeitet werden. Ein Batch wird gemeinsam im Speicher gehalten. Ein Gruppenfoto mit vierzig Gesichtern benötigt daher mehr Speicher als ein Porträt.
• Welche Modelltypen überhaupt ausgeführt werden. Intelligente Suche, Gesichtserkennung und Texterkennung laden jeweils eigene Modelle. Wenn Sie nicht benötigte Funktionen unter Administration, Settings, Machine Learning Settings deaktivieren, wird der dafür benötigte Speicher dauerhaft freigegeben und nicht nur zwischen Importen.

Außerdem gibt es MACHINE_LEARNING_MODEL_ARENA. Diese Option ist dokumentiert als Vorabreservierung von CPU-Speicher zur Vermeidung von Fragmentierung und standardmäßig aktiviert. Ändern Sie diese Einstellung zuletzt. Ihre Auswirkung hängt vom verwendeten Speicher-Allocator ab. Die einzige zuverlässige Methode zur Bewertung besteht daher darin, docker stats vor und nach der Änderung zu überwachen.

Drei funktionierende Profile: 2 GB, 4 GB und 8 GB

[
  {
    "label": "2 GB VPS",
    "server_limit_mb": 768,
    "db_limit_mb": 768,
    "ml_limit_mb": 0,
    "redis_limit_mb": 128,
    "notes": "below every documented configuration, machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 2048,
    "ml_limit_mb": 0,
    "redis_limit_mb": 192,
    "notes": "documented 4 GB setup: machine learning disabled or moved to another host, job concurrency 1"
  },
  {
    "label": "8 GB VPS",
    "server_limit_mb": 2048,
    "db_limit_mb": 2048,
    "ml_limit_mb": 2560,
    "redis_limit_mb": 256,
    "notes": "everything on at default settings"
  }
]

Betrachten Sie diese Werte als Limits für die Eingabe in Compose, nicht als Messwerte für den tatsächlichen Verbrauch von Immich. Ein Limit ist eine Obergrenze. Es reserviert keine Ressourcen und verkleinert einen Dienst nicht. Es legt fest, welchen Dienst der Kernel beendet, wenn der Arbeitsspeicher erschöpft ist – eine Entscheidung, die Sie besser selbst treffen, als sie der automatischen Bewertung des Kernels zu überlassen.

Das 2-GB-System: Entfernen des Machine-Learning-Containers

2 GB liegen unter dem dokumentierten Minimum von 6 GB und unter der einzigen von Immich dokumentierten reduzierten Konfiguration, die 4 GB bei deaktiviertem Machine Learning vorsieht. Immich bietet keine 2-GB-Konfiguration an; dieses Profil ist daher ein nicht unterstützter Kompromiss und keine offizielle Anleitung. Falls Sie es dennoch versuchen, kommentieren Sie den gesamten Dienst immich-machine-learning in docker-compose.yml aus oder lassen Sie ihn laufen und deaktivieren Sie jedes Modell unter Administration, Settings, Machine Learning Settings. Das Entfernen des Containers ist die sicherere Option, da ein deaktiviertes Modell weiterhin einen Python-Prozess im Speicher hält.

Sie behalten Funktionen wie Uploads, Alben, Teilen, mobiles Backup, Vorschaubilder sowie die Suche nach Datum, Ort und Dateiname. Sie verlieren die Suche nach Beschreibung, die automatische Gruppierung von Gesichtern zu Personen sowie die Texterkennung innerhalb von Bildern.

Die vier Limits summieren sich auf etwa 1,7 GB, was dem Host etwa 300 MB lässt. Die Immich-Dokumentation besagt, dass die Datenbank allein mindestens 2 GB benötigt, sobald Docker-Ressourcenlimits aktiv sind, was hier das gesamte System umfasst. Daher liegt 768 MB für die Datenbank deutlich unter diesem Mindestwert, weshalb Postgres hier am ehesten vom Kernel beendet wird.

Was zuerst ausfällt, ist der Import. Das Ausliefern einer Seite ist eine Metadatenabfrage plus ein Dateilesevorgang; das Durchsuchen einer bereits vorhandenen Bibliothek belastet das System also am wenigsten. Ein videolastiger Import führt jedoch zum Auslagern in den Swap, da Transkodierung und die Warteschlange für Vorschaubilder gleichzeitig Arbeitsspeicher anfordern. Wenn Ihnen nur 2 GB zur Verfügung stehen, setzen Sie die Parallelität für alle rechenintensiven Warteschlangen auf 1 und richten Sie eine Swap-Datei ein. Wenn Sie eine Wahl treffen, betrachten Sie 4 GB als das tatsächliche Minimum.

Das 4-GB-System: Machine Learning aktiv, ein Job nach dem anderen

Immich dokumentiert 4 GB als funktionsfähig bei deaktivierten Machine-Learning-Funktionen; dies ist die einzige reduzierte Konfiguration auf der Anforderungsseite. Mit der Datenbank am dokumentierten 2-GB-Minimum summieren sich die drei Limits im Diagramm auf etwa 3,2 GB, was dem Host etwa 800 MB lässt. Setzen Sie die Job-Parallelität für die Generierung von Vorschaubildern auf 1 und halten Sie die Anzahl der Transkodierungs-Threads niedrig.

Um Gesichts- und Objekterkennung beizubehalten, ist der dokumentierte Weg, den Machine-Learning-Container auf einer anderen Maschine auszuführen (wie unten beschrieben) und diesen Server darauf zu verweisen. Der Betrieb auf demselben 4-GB-System überschreitet die Immich-Vorgaben, da das Datenbank-Minimum nur etwa 2 GB für den Server, Redis, die Modelle und den Host zusammen lässt. Falls Sie es dennoch versuchen, begrenzen Sie den Machine-Learning-Container mit einem Compose-Limit, stellen Sie die Gesichtserkennung auf buffalo_s um und setzen Sie die Job-Parallelität für Vorschaubilder, Gesichtserkennung und intelligente Suche auf 1.

Der erste Durchlauf einer bestehenden Bibliothek dauert viele Stunden, bei einer großen Bibliothek mehr als einen Tag. Dies ist eher durch die CPU als durch den Arbeitsspeicher begrenzt, daher verkürzt mehr RAM den Vorgang nicht.

Wenn Machine Learning auf diesem System läuft, fällt während des ersten Massendurchlaufs zuerst dieser Container aus. Ohne Limit wächst er, während gleichzeitig ein Transkodierungs-Job wächst, und der Kernel beendet den größeren der beiden. Da er innerhalb von Sekunden neu startet, zeigt docker ps -a ihn als Up mit einer deutlich kürzeren Laufzeit als seine Nachbarn an, anstatt als Exited (137), und die Warteschlange ist unbemerkt weiter zurückgefallen, als Sie zuletzt nachgesehen haben.

Das 8-GB-System: Die dokumentierte Empfehlung

8 GB mit 4 Kernen entsprechen der Empfehlung von Immich, und alles läuft mit Standardeinstellungen: intelligente Suche, Gesichtserkennung, Texterkennung und Transkodierung bei Standard-Parallelität. Bibliotheken mit über hunderttausend Objekten laufen hier problemlos, und der Engpass verlagert sich vom Arbeitsspeicher auf die Festplattengeschwindigkeit, da der Vektorindex und die Metadatenabfragen die Hauptlast der Datenbank darstellen.

Setzen Sie die Limits dennoch. Auf einem System mit Reserven verhindern die Limits, dass eine außer Kontrolle geratene Warteschlange die Datenbank mit in den Abgrund reißt. Wenn Sie dies preislich mit den kleineren Optionen vergleichen, ist was ein VPS nach Speicherklasse tatsächlich kostet meist der Grund, warum der 8-GB-Plan der günstigste Weg ist, um sich das Tuning zu sparen.

Speicherbegrenzung pro Dienst mit Compose-Limits

Bearbeiten Sie dafür nicht docker-compose.yml. Diese Datei wird bei jedem Upgrade durch wget überschrieben. Tragen Sie die Limits stattdessen in die daneben liegende Datei docker-compose.override.yml ein, welche docker compose automatisch zusammenführt.

services:
  immich-server:
    deploy:
      resources:
        limits:
          memory: 1024M
  immich-machine-learning:
    deploy:
      resources:
        limits:
          memory: 1024M
          cpus: '1.5'
  database:
    deploy:
      resources:
        limits:
          memory: 2048M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

docker compose up -d
docker stats --no-stream

docker stats sollte nun Ihre Obergrenze in der Spalte MEM USAGE / LIMIT anzeigen und nicht mehr den Gesamtspeicher des Hosts. Falls in der Limit-Spalte weiterhin die volle Host-Größe steht, wurde die Override-Datei nicht geladen: Überprüfen Sie den Dateinamen und führen Sie docker compose config aus, um das zusammengeführte Ergebnis zu prüfen.

Belassen Sie die Datenbank bei mindestens 2048M. Immich gibt 2 GB als Untergrenze für die Datenbank an, sobald Docker-Ressourcenlimits verwendet werden. Ein zu niedriges Limit macht aus einem langsamen Dienst einen nicht funktionierenden; erhöhen Sie den Wert, falls ein Container in eine Neustartschleife gerät. Weitere Details zur Funktionsweise finden Sie unter Speicherlimits pro Dienst in Docker Compose festlegen, einschließlich der Erklärung, warum deploy außerhalb von Swarm mit Compose v2 funktioniert.

Deaktivieren oder Verschieben des Machine-Learning-Containers

Auf einem kleinen Server ist das Verschieben dieses Containers die effektivste Maßnahme zur Entlastung. Immich unterstützt den Betrieb auf einer anderen Maschine. Erstellen Sie diese Datei auf dem zweiten Host, bei dem es sich auch um einen Desktop-Rechner handeln kann, der nur abends eingeschaltet ist:

name: immich_remote_ml
services:
  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    restart: always
    ports:
      - 3003:3003
volumes:
  model-cache:

docker compose up -d
curl -s http://localhost:3003/ping

Navigieren Sie anschließend im Webinterface zu Administration, Settings, Machine Learning Settings, klicken Sie auf Add URL und geben Sie http://<host>:3003 ein. Achten Sie darauf, dass die Version auf beiden Hosts identisch ist, da die Immich-Dokumentation vor Fehlern und Instabilität bei Versionsunterschieden warnt.

Über diesen Port werden Bildvorschauen Ihrer Fotos unverschlüsselt an die andere Maschine übertragen. Da der Immich-Machine-Learning-Container laut Dokumentation über keine eigenen Sicherheitsmechanismen verfügt, sollte er nur in einem privaten Netzwerk betrieben oder über einen WireGuard-Tunnel zwischen den beiden Hosts angebunden werden. Port 3003 darf niemals direkt aus dem Internet erreichbar sein.

Falls das Grundkonzept eines permanent laufenden Modell-Containers das Problem darstellt, ist dies ein valider Grund, die Unterschiede zwischen PhotoPrism und Immich hinsichtlich der Systemlast im Ruhezustand zu vergleichen, bevor Sie sich für eine bestimmte Infrastruktur entscheiden.

Wie viel Speicherplatz benötigt eine Immich-Bibliothek?

Dafür gibt es keinen einzelnen Multiplikator, weil vier verschiedene Bereiche unterschiedlich schnell wachsen. Hier ist die Berechnung für eine Bibliothek mit 50,000 Fotos und 500 kurzen Videos.

[
  {
    "label": "Originals: 50,000 photos at 4 MB",
    "gb": 200
  },
  {
    "label": "Originals: 500 videos at 120 MB",
    "gb": 60
  },
  {
    "label": "Thumbnails and encoded video at 15%",
    "gb": 39
  },
  {
    "label": "Postgres database",
    "gb": 3
  },
  {
    "label": "Machine learning model cache",
    "gb": 2
  }
]

Die 200 GB für Fotos und die 60 GB für Videos sind Annahmen. Ersetzen Sie diese Werte vor dem Kauf durch Ihre eigenen Durchschnittswerte, denn Videos bestimmen diese Zahl: Eine Minute Handyvideo ist größer als hundert Fotos.

find /srv/immich/upload -type f -printf '%s\n' \
  | awk '{n++; s+=$1} END {printf "%d files, %.1f MB average\n", n, s/n/1048576}'

Die Zeile mit 39 GB ist das einzige von Immich veröffentlichte Verhältnis: Generierte Vorschaubilder und transkodierte Videos erhöhen die Größe der Bibliothek durchschnittlich um 10 bis 20 Prozent. Es handelt sich um eine Spanne, weil sie davon abhängt, wie viele Ihrer Dateien Videos sind, die für die Browserkompatibilität neu codiert werden müssen. Eine Bibliothek mit JPEGs liegt nahe am unteren Ende dieser Spanne.

Die Datenbank benötigt 3 GB. Das entspricht annähernd einem festen Bedarf. Immich gibt für Datenbankdateien typischerweise 1 bis 3 GB an, weil sie Metadaten und Suchvektoren statt Pixeln enthalten. Der Modell-Cache benötigt 2 GB und wächst, wenn Sie mehrere Modelle aktivieren oder verschiedene Modelle testen. Die FAQ weist dieses Verzeichnis genau aus diesem Grund als Speicherverbraucher aus.

Die fünf Zeilen ergeben etwas mehr als 300 GB. Ein Volume mit 500 GB lässt daher noch Raum für Wachstum, ein Volume mit 250 GB dagegen nicht. Prüfen Sie die Aufteilung mit:

grep UPLOAD_LOCATION .env
du -sh /srv/immich/*

Unter UPLOAD_LOCATION liegen sechs Verzeichnisse. upload und library enthalten die Originale, thumbs enthält Vorschauen und Gesichtsvorschaubilder, encoded-video enthält neu codierte Kopien, profile enthält Avatare und backups enthält automatische Datenbank-Dumps. Nur upload, library und profile sind nicht ersetzbar, weil alle anderen Daten daraus neu erzeugt werden.

Zwei Dinge überraschen viele Benutzer. Gelöschte Dateien werden zunächst in den Papierkorb verschoben und belegen ihren Speicherplatz, bis der Papierkorb geleert wird. Eine umfangreiche Bereinigung gibt daher am selben Tag keinen Speicherplatz frei. Außerdem enthält ein Datenbank-Dump nur Metadaten und ist ohne die Dateien wertlos:

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gz

Kombinieren Sie das mit einer Kopie der Originale auf Dateiebene an einem Ort außerhalb des Servers. Genau dafür sind restic-Backups von einem VPS auf externen Speicher vorgesehen.

Transkodierung wird durch die CPU begrenzt, nicht durch den Arbeitsspeicher

Mehr RAM macht die Transkodierung nicht schneller. Immich verwendet dafür FFmpeg. Auf einem gewöhnlichen VPS werden alle Frames durch die CPU decodiert und codiert. Jeder FFmpeg-Prozess hält weiterhin Puffer mit decodierten Frames im Arbeitsspeicher. Deshalb wird eine Transkodierung im Abschnitt zum Import als eigener Speicherbedarf berücksichtigt. Ihre Geschwindigkeit hängt jedoch von der CPU ab. Selbst wenn Hardwarebeschleunigung verfügbar ist, wird laut Immich standardmäßig nur die Codierung beschleunigt. Die CPU übernimmt weiterhin die Decodierung und das Tone Mapping, sofern Sie nicht zusätzlich die Hardwaredecodierung aktivieren.

Für die Hardwarebeschleunigung benötigen Sie die zusätzliche hwaccel.transcoding.yml Compose-Datei sowie ein Gerät, das mit NVENC, Quick Sync, RKMPP oder VAAPI durchgereicht wird. Die meisten VPS-Tarife stellen keine dieser Optionen bereit. Planen Sie daher mit CPU-Leistung.

Die praktische Einstellung ist die Anzahl der Threads. Unter Administration, Settings, Video Transcoding Settings bedeutet ein Thread-Wert von 0, dass alle Kerne verwendet werden. Dadurch kann ein einzelnes Video die Weboberfläche auf einem Tarif mit 2 Kernen blockieren. Setzen Sie den Wert dort auf 1 oder 2, wie es die Immich-FAQ empfiehlt. Dann wird die Transkodierung langsam, beeinträchtigt den Betrieb aber nicht.

Warum ein durch Swap ausgelöster Thrashing-Import wie ein Hänger aussieht

Dies ist der Fehler, der am häufigsten falsch interpretiert wird. Wenn Immich keinen Arbeitsspeicher mehr hat, gibt es zwei mögliche Folgen. Nur eine davon sieht wie ein Fehler aus.

Ohne Swap beendet der Kernel einen Prozess. Der Container wird innerhalb weniger Sekunden neu gestartet. Im Browser scheint die Auftragswarteschlange daher einfach anzuhalten und anschließend fortzufahren. Die Hinweise finden Sie in docker ps -a:

docker ps -a --filter name=immich
docker inspect immich_machine_learning | grep -i oomkilled
sudo dmesg -T | grep -i -E 'out of memory|oom-kill'

Exited (137) bedeutet, dass der Prozess mit Signal 9 beendet wurde. 137 entspricht 128 plus 9. Diesen Status sehen Sie nur, solange der Container gestoppt ist. Sobald die Restart-Richtlinie ihn wieder gestartet hat, zeigt docker ps -a erneut Up. Eine deutlich kürzere Laufzeit als bei den anderen Immich-Containern ist dann der entscheidende Hinweis. Signal 9 allein beweist kein Speicherproblem, weil Docker es auch sendet, wenn ein normaler Stopp das Timeout überschreitet. Ein Wert OOMKilled von true bestätigt, dass der Prozess wegen Speichermangels beendet wurde. Nach dem Neustart des Containers sind die oom-kill-Zeilen aus dmesg die verlässliche Informationsquelle.

Mit Swap wird nichts beendet und kein Fehler gemeldet. Der Kernel verschiebt Seiten auf die Festplatte. Der Import wird dadurch um eine Größenordnung langsamer, und die Weboberfläche antwortet innerhalb eines normalen Timeouts nicht mehr. Alle Container laufen. Alle Health Checks können weiterhin erfolgreich sein. Es sieht wie ein Hänger aus. An diesem Punkt starten viele Administratoren den Server neu. Dadurch geht der Fortschritt der Warteschlange verloren, ohne dass sich die Ursache ändert.

free -m
vmstat 1 5

Anhaltende Werte ungleich null in den Spalten si und so von vmstat bedeuten, dass der Rechner fortlaufend Swap liest und schreibt. Das ist die Definition von Thrashing. Der Wert in der Zeile free -m für Swap wird gleichzeitig steigen.

Richten Sie auf einem Rechner mit 2 GB oder 4 GB trotzdem Swap ein. Einen langsamen, diagnostizierbaren Import können Sie beheben. Einen beendeten Container können Sie nicht diagnostizieren:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Beheben Sie anschließend die Ursache. Setzen Sie die Parallelität der Aufträge auf 1, begrenzen Sie den Machine-Learning-Container oder verschieben Sie ihn auf einen anderen Host. Swap verschafft Ihnen dafür Zeit. Swap allein ist keine Lösung.

FAQ

Kann ich Immich auf einem 2 GB VPS betreiben?

Nicht in einer Konfiguration, die von Immich dokumentiert wird. Die Anforderungsseite setzt 6 GB als Minimum fest, nennt 4 GB bei deaktivierten Machine-Learning-Funktionen als einziges kleineres Setup und gibt an, dass die Datenbank allein mindestens 2 GB benötigt, sobald Docker-Ressourcenlimits genutzt werden. Das Auskommentieren des immich-machine-learning-Dienstes und das Setzen der Job-Parallelität auf 1 kann den Betrieb ermöglichen, dies ist jedoch ein nicht unterstützter Kompromiss, und Postgres ist der Dienst, der bei einem Import am wahrscheinlichsten beendet wird. Wenn Ihnen nur 2 GB zur Verfügung stehen, fügen Sie eine 2 GB Swap-Datei hinzu, damit eine Import-Spitze den Server verlangsamt, anstatt einen Container zu beenden. Wenn Sie einen Tarif wählen, beginnen Sie bei 4 GB.

Warum stoppt mein Immich-Import ohne Fehlermeldung?

Zwei verschiedene Ursachen sehen im Browser identisch aus. Entweder wurde ein Container wegen Speichermangels beendet und ist bereits neu gestartet; in diesem Fall zeigt docker ps -a ihn Up mit einer verdächtig kurzen Laufzeit an (Exited (137) erscheint nur, wenn Sie ihn erwischen, während er gestoppt ist). Oder der Host nutzt Swap, wodurch alle Container zwar noch laufen, aber alles extrem langsam ist. vmstat 1 5 unterscheidet diese Fälle: Anhaltende Werte ungleich Null in den Spalten si und so bedeuten, dass geswappt wird. Reduzieren Sie in beiden Fällen die Job-Parallelität für die Generierung von Vorschaubildern, Gesichtserkennung und intelligente Suche.

Was bedeutet Exit-Code 137 in den Immich-Logs?

137 ist 128 plus Signal 9, der Prozess wurde also mit SIGKILL beendet. Auf einem Immich-System ist dies meist ein Speichermangel, entweder durch das Limit des Containers selbst oder weil der Host keinen Speicher mehr hat. Der Code allein beweist dies jedoch nicht: Docker sendet auch SIGKILL, wenn ein Container nicht innerhalb seines Timeouts stoppt (standardmäßig 10 Sekunden unter Linux). Prüfen Sie dies mit docker inspect immich_machine_learning | grep -i oomkilled. Ein Wert von true bestätigt, dass der Kernel den Prozess wegen Speichermangels beendet hat, und free -m plus sudo dmesg -T | grep -i oom-kill verraten Ihnen dann, ob das Container-Limit oder der gesamte Host betroffen war. Der Machine-Learning-Container ist das übliche Opfer, da er meist der größte Prozess ist.

Wie viel Speicherplatz benötigt Immich pro Foto?

Planen Sie die Originaldatei plus 10 bis 20 Prozent ein. Immich dokumentiert, dass generierte Vorschaubilder und transkodierte Videos die Bibliotheksgröße im Durchschnitt um 10 bis 20 Prozent erhöhen, und die Datenbank selbst ist typischerweise 1 bis 3 GB groß, selbst bei einer großen Bibliothek. Videos bestimmen letztlich Ihren Gesamtbedarf; messen Sie daher Ihre durchschnittliche Dateigröße, bevor Sie einen Tarif wählen, anstatt einen Multiplikator auf die Anzahl der Fotos anzuwenden.

Benötige ich eine GPU für Immich?

Nein. Jeder Teil von Immich läuft auf der CPU. Eine Grafikkarte beschleunigt die Modell-Inferenz im Machine-Learning-Container sowie die Videokodierung, beides ist jedoch nicht erforderlich. Die meisten VPS-Tarife bieten keine GPU an. Auf Hardware, die nur über eine CPU verfügt, setzen Sie die Transkodierungs-Threads auf 1 oder 2, verwenden Sie das buffalo_s-Gesichtsmodell und lassen Sie den ersten Massenimport über Nacht laufen.