Wie viel RAM und Speicherplatz braucht Immich?

Wie viel RAM benötigt Immich?

Immich benötigt laut Dokumentation mindestens 6 GB RAM (Arbeitsspeicher) und empfiehlt 8 GB. Dafür sind mindestens 2 CPU-Kerne und für eine komfortable Installation 4 CPU-Kerne vorgesehen. Diese Angabe gilt für den gesamten Stack, weil Immich aus vier Containern und nicht aus einer einzelnen Anwendung besteht. Das Durchsuchen einer bereits importierten Bibliothek benötigt wenig Ressourcen. Der Speicherbedarf entsteht beim Import. Der größte Teil entfällt auf einen Container, den Sie deaktivieren können.

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

Das sind die veröffentlichten Werte aus der Immich-Anforderungsseite mit Stand August 2026. Sie dienen zur Dimensionierung und sind keine Prüfung, die beim Start der Software durchgeführt wird. Immich startet auch mit weniger Ressourcen. Auf einem kleineren Server ändert sich, welche Hintergrundaufgaben abgeschlossen werden und was beim Import passiert, wenn der Speicher nicht ausreicht.

Es gibt eine echte harte Grenze. Immich Version 3 und höher benötigt auf amd64-Hosts eine x86-64-v2 CPU. Das betrifft die meisten Prozessoren, die seit ungefähr 2012 verkauft wurden. Auf älterer Hardware startet der Container nicht, anstatt lediglich langsamer zu laufen.

Wenn die Installation noch bevorsteht, beginnen Sie mit der vollständigen Immich-Installation auf einem VPS mit Docker Compose und kehren Sie anschließend hierher zurück, um den Server zu dimensionieren.

Wohin der Speicher geht: vier Container

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

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

database ist ein PostgreSQL-14-Image mit integrierter VectorChord-Erweiterung. Es enthält sämtliche Metadaten und einen Suchvektor pro Asset. Die Immich-Dokumentation nennt für diesen Dienst die einzige explizite Mindestanforderung im Stack: Wenn Sie Docker-Ressourcenlimits festlegen, benötigt die Datenbank mindestens 2 GB. Auf derselben Seite steht, dass die Datenbank auf lokalem SSD-Speicher und niemals auf einer Netzwerkfreigabe beliebiger Art liegen darf. Vektor- und Indexabfragen bestehen aus kleinen zufälligen Lesezugriffen. Ein Netzwerkvolume macht daraus jeweils einen Roundtrip. Wenn davon eine Planentscheidung abhängt, 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 enthält die Job-Warteschlangen. Es ist mit großem Abstand der kleinste der vier Container, weil es Jobdatensätze 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 Arbeitsspeicher. 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 geladen. Während eines Massenimports gibt es nie eine Lücke von fünf Minuten. Deshalb bleiben die Modelle 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 getestete 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": "machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 1280,
    "ml_limit_mb": 1024,
    "redis_limit_mb": 192,
    "notes": "machine learning on, job concurrency 1, buffalo_s"
  },
  {
    "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"
  }
]

Verwenden Sie diese Werte als Limits, die Sie in Compose eintragen, nicht als Messwerte für den tatsächlichen Speicherbedarf von Immich. Ein Limit ist eine Obergrenze. Es reserviert keinen Speicher und macht einen Dienst nicht kleiner. Es legt fest, welchen Dienst der Kernel beendet, wenn dem Server der Speicher ausgeht. Diese Entscheidung treffen besser Sie als die eigene Bewertung des Kernels.

Der Server mit 2 GB: Container für maschinelles Lernen entfernen

2 GB liegen unter dem dokumentierten Mindestwert von 6 GB. Das ist ein Kompromiss, den Sie als solchen benennen sollten. Kommentieren Sie den gesamten Dienst immich-machine-learning in docker-compose.yml aus. Alternativ können Sie ihn weiter ausführen und jedes Modell unter Administration, Settings, Machine Learning Settings deaktivieren. Den Container zu entfernen, ist die bessere Option, weil ein deaktiviertes Modell weiterhin einen Python-Prozess im Speicher belässt.

Uploads, Alben, Freigaben, mobile Backups sowie die Suche nach Datum, Ort und Dateiname bleiben verfügbar. Sie verlieren die Suche nach Beschreibung, die automatische Gruppierung von Gesichtern zu Personen und die Texterkennung in Bildern.

Die vier Limits ergeben zusammen etwa 1.7 GB. Für den Host bleiben damit ungefähr 300 MB. Beachten Sie, dass 768 MB für die Datenbank unter dem dokumentierten Mindestwert von 2 GB liegen. Genau das ist der Kompromiss, den 2 GB erzwingen. Deshalb wird Postgres hier am wahrscheinlichsten beendet.

Zuerst scheitert der Import, nicht das Durchsuchen der Bibliothek. Eine Bibliothek mit einigen zehntausend Fotos lässt sich nach dem Import akzeptabel durchsuchen, weil das Ausliefern einer Seite aus einer Metadatenabfrage und einem Dateizugriff besteht. Ein videolastiger Import auf demselben Server führt zu Auslagerungen, weil eine Transkodierung und eine Thumbnail-Warteschlange gleichzeitig Speicher benötigen. Setzen Sie die Parallelität jeder rechenintensiven Warteschlange auf 1 und fügen Sie eine Swap-Datei hinzu.

Der Server mit 4 GB: maschinelles Lernen aktiviert, ein Auftrag gleichzeitig

4 GB sind die kleinste Größe, bei der sich das Aktivieren der Gesichts- und Objekterkennung lohnt. Begrenzen Sie den Container für maschinelles Lernen auf 0 MB, stellen Sie die Gesichtserkennung auf buffalo_s und setzen Sie die Auftragsparallelität für Thumbnail-Erstellung, Gesichtserkennung und intelligente Suche auf 1.

Der erste Durchlauf über eine vorhandene Bibliothek dauert viele Stunden, bei einer großen Bibliothek mehr als einen Tag. Das ist eine CPU-Begrenzung und keine Speicherbegrenzung. Mehr RAM verkürzt den Durchlauf daher nicht.

Hier wird zuerst der Container für maschinelles Lernen während dieses ersten Massendurchlaufs beendet. Ohne Limit wächst sein Speicherbedarf, während auch ein Transkodierungsauftrag wächst. Der Kernel beendet dann den größeren der beiden Prozesse. In docker ps -a sehen Sie Exited (137) und einen neu gestarteten Container. Die Warteschlange ist dabei unbemerkt weiter zurückgefallen als bei Ihrer letzten Prüfung.

Der Server mit 8 GB: die dokumentierte Empfehlung

8 GB mit 4 Kernen entsprechen der Empfehlung von Immich. Alles läuft mit den Standardeinstellungen: intelligente Suche, Gesichtserkennung, Texterkennung und Transkodierung mit der standardmäßigen Parallelität. Bibliotheken mit mehr als hunderttausend Assets laufen hier problemlos. Die Belastung verlagert sich vom Speicher auf die Datenträgergeschwindigkeit, weil die Datenbank den Vektorindex und die Metadatenabfragen den ganzen Tag verarbeitet.

Setzen Sie die Limits trotzdem. Auf einem Server mit ausreichend Ressourcen verhindern die Limits, dass eine außer Kontrolle geratene Warteschlange die Datenbank mit herunterzieht. Wenn Sie dieses Profil mit den kleineren Optionen vergleichen, macht was ein VPS je nach Speichergröße tatsächlich kostet den 8-GB-Tarif normalerweise zur günstigsten Möglichkeit, weiteren Konfigurationsaufwand zu vermeiden.

Begrenzung des Arbeitsspeichers pro Dienst mit Compose-Limits

Ändern Sie docker-compose.yml dafür nicht. Diese Datei wird bei jedem Upgrade durch wget ersetzt. Tragen Sie die Limits stattdessen in docker-compose.override.yml daneben ein. docker compose führt diese Datei automatisch zusammen.

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

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

docker stats sollte jetzt in der Spalte MEM USAGE / LIMIT Ihr Limit statt des gesamten Arbeitsspeichers des Hosts anzeigen. Wenn die Limit-Spalte weiterhin die vollständige Größe des Hosts enthält, wurde die Override-Datei nicht geladen. Prüfen Sie den Dateinamen und führen Sie docker compose config aus, um das zusammengeführte Ergebnis anzuzeigen.

Ein zu niedriges Limit macht aus einem langsamen Dienst einen ausgefallenen Dienst. Erhöhen Sie das Limit, wenn ein Container wiederholt neu gestartet wird. Weitere Informationen zu den technischen Hintergründen finden Sie unter Arbeitsspeicherlimits pro Dienst in Docker Compose festlegen. Dort wird auch erklärt, warum deploy außerhalb von Swarm mit Compose v2 funktioniert.

Machine-Learning-Container deaktivieren oder verschieben

Auf einem kleinen Server ist das Verschieben dieses Containers die wirksamste einzelne Maßnahme. Immich unterstützt den Betrieb auf einem anderen Rechner. Erstellen Sie diese Datei auf dem zweiten Host. Das kann beispielsweise ein Desktop sein, 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

Öffnen Sie anschließend im Webinterface Administration, Settings, Machine Learning Settings. Klicken Sie auf Add URL und geben Sie http://<host>:3003 ein. Verwenden Sie auf beiden Hosts dieselbe Version. Die Immich-Dokumentation warnt, dass Versionsabweichungen zwischen den beiden Hosts Fehler und Instabilität verursachen.

Über diesen Port werden Ihre Fotos unverschlüsselt an den anderen Rechner übertragen. Verwenden Sie daher ein privates Netzwerk oder übertragen Sie den Datenverkehr über einen WireGuard-Tunnel zwischen den beiden Hosts. Port 3003 darf niemals aus dem Internet erreichbar sein.

Wenn der dauerhaft laufende Modell-Container grundsätzlich problematisch ist, sollten Sie vor der Auswahl eines Tarifs auch die Unterschiede zwischen PhotoPrism und Immich beim dauerhaft laufenden Betrieb vergleichen.

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.

Transcodierung nutzt die CPU, nicht den RAM

Mehr RAM macht die Transcodierung nicht schneller. Immich verwendet FFmpeg. Auf einem gewöhnlichen VPS werden daher alle Frames von der CPU decodiert und codiert. Selbst wenn Hardwarebeschleunigung verfügbar ist, wird laut Immich nur die Codierung beschleunigt. Die CPU übernimmt weiterhin die Software-Decodierung und das Tonemapping.

Für die Hardwarebeschleunigung benötigen Sie die zusätzliche hwaccel.transcoding.yml Compose-Datei und ein Gerät, das per Passthrough durchgereicht wird. Unterstützt werden NVENC, Quick Sync, RKMPP oder VAAPI. Die meisten VPS-Tarife bieten keine dieser Möglichkeiten. 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 einfrieren. Setzen Sie den Wert dort auf 1 oder 2, wie es die Immich-FAQ empfiehlt. Dann wird die Transcodierung langsam, stört den Betrieb aber nicht.

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

Dies ist der Fehler, der am häufigsten falsch interpretiert wird. Wenn Immich nicht mehr genügend Arbeitsspeicher 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 lediglich anzuhalten und anschließend fortzufahren. Die entsprechenden Hinweise stehen 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. Ein Wert OOMKilled von true bestätigt, dass der Prozess wegen Speichermangels und nicht wegen eines Absturzes beendet wurde.

Mit Swap wird nichts beendet und es tritt kein Fehler auf. Der Kernel verschiebt Speicherseiten auf die Festplatte. Der Import wird dadurch um eine Größenordnung langsamer, und die Weboberfläche antwortet nicht mehr innerhalb eines normalen Timeouts. Jeder Container läuft weiter. Jeder Health-Check kann 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 kontinuierlich aus dem Swap liest und in den Swap schreibt. Das ist die Definition von Thrashing. Gleichzeitig steigt der Wert in der Zeile free -m für Swap used an.

Fügen Sie auf einem Rechner mit 2 GB oder 4 GB trotzdem Swap hinzu. 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. Reduzieren Sie die Anzahl paralleler Aufträge auf 1, begrenzen Sie den Container für maschinelles Lernen oder verschieben Sie ihn auf einen anderen Host. Swap verschafft Ihnen dafür Zeit. Swap allein ist jedoch keine Lösung.

FAQ

Kann ich Immich auf einem VPS mit 2 GB ausführen?

Ja, wenn der Dienst immich-machine-learning in docker-compose.yml auskommentiert ist und die Anzahl paralleler Jobs auf 1 gesetzt wird. Das liegt unter dem dokumentierten Mindestbedarf von 6 GB und ist daher ein bekannter Kompromiss. Uploads, Alben, Freigaben, mobile Backups sowie die Suche nach Datum, Ort und Dateiname bleiben verfügbar. Die Suche nach Beschreibung, die automatische Gruppierung von Gesichtern zu Personen und die Texterkennung in Bildern entfallen. Legen Sie eine 2-GB-Swap-Datei an, damit ein Importanstieg den Server verlangsamt, statt dass ein Container beendet wird.

Warum wird mein Immich-Import ohne Fehlermeldung beendet?

Im Browser sehen zwei verschiedene Ursachen gleich aus. Entweder wurde ein Container wegen Speichermangels beendet. Dann zeigt docker ps -a den Wert Exited (137), und der Container wurde bereits neu gestartet. Oder der Host verwendet Swap. Dann laufen alle Container weiterhin, und alles ist lediglich sehr langsam. vmstat 1 5 unterscheidet die beiden Fälle: Anhaltende Werte ungleich null in den Spalten si und so weisen auf die Verwendung von Swap hin. Verringern Sie in beiden Fällen die Anzahl paralleler Jobs für die Thumbnail-Erstellung, die Gesichtserkennung und die intelligente Suche.

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

137 entspricht 128 plus Signal 9. Der Prozess wurde daher mit SIGKILL beendet. In der Praxis bedeutet das, dass eine Speichergrenze erreicht wurde. Entweder wurde das eigene Limit des Containers erreicht, oder dem Host ging der Speicher aus. Prüfen Sie dies mit docker inspect immich_machine_learning | grep -i oomkilled. Der Wert true bestätigt, dass der Kernel den Prozess wegen Speichermangels beendet hat. Mit free -m plus sudo dmesg -T | grep -i oom-kill lässt sich anschließend feststellen, ob das Containerlimit oder der gesamte Host die Ursache war. Der Machine-Learning-Container ist meist betroffen, weil er in der Regel der größte Prozess ist.

Wie viel Speicherplatz benötigt Immich pro Foto?

Planen Sie die Größe der Originaldatei plus 10 bis 20 Prozent ein. Laut Immich vergrößern erzeugte Thumbnails und transkodierte Videos die Bibliotheksgröße durchschnittlich um 10 bis 20 Prozent. Die Datenbank benötigt selbst bei einer großen Bibliothek typischerweise 1 bis 3 GB. Videos bestimmen den Gesamtbedarf. Messen Sie daher vor der Auswahl eines Tarifs Ihre eigene durchschnittliche Dateigröße, statt einen Multiplikator auf die Anzahl der Fotos anzuwenden.

Benötige ich für Immich eine GPU?

Nein. Jeder Bestandteil von Immich läuft auf der CPU. Eine Grafikkarte beschleunigt die Modellinferenz im Machine-Learning-Container und die Videokodierung. Beides ist jedoch nicht erforderlich. Die meisten VPS-Tarife bieten keine GPU an. Setzen Sie auf Hardware ausschließlich mit CPU die Transkodierungs-Threads auf 1 oder 2, verwenden Sie das Gesichtsmodell buffalo_s und lassen Sie den ersten Massenimport über Nacht laufen.