Hardware, SSD, RAM, CPU, GPU und Docker sinnvoll abstimmen

Immich kann auf erstaunlich kleiner Hardware betrieben werden.

Das bedeutet allerdings nicht automatisch, dass jede Installation auch schnell ist.

Zwischen:

20.000 Fotos

und:

250.000 Fotos
+
15.000 Videos
+
Smart Search
+
Gesichtserkennung
+
mehreren Benutzern

liegen völlig unterschiedliche Anforderungen.

Besonders beim ersten Import entstehen zahlreiche Hintergrundaufgaben. Immich muss Metadaten auslesen, Vorschaubilder erzeugen, Videos verarbeiten, Smart-Search-Embeddings berechnen und Gesichter analysieren.

Die Folge kann sein:

• hohe CPU-Auslastung
• starke Datenträgeraktivität
• viel Arbeitsspeicherverbrauch
• langsame Weboberfläche
• verzögerte Suchergebnisse
• lange Job-Warteschlangen

Das Gute daran:

Viele dieser Engpässe lassen sich gezielt optimieren.

In diesem elften Teil unserer Serie betrachten wir die wichtigsten Stellschrauben – von SSD und Arbeitsspeicher über CPU und GPU bis hin zu Docker, PostgreSQL, Thumbnail-Generierung und Machine Learning.

Wo entstehen die größten Belastungen?

Ein neues Foto durchläuft in Immich mehrere Verarbeitungsschritte.

Vereinfacht:

Upload
  │
  ▼
Metadaten extrahieren
  │
  ▼
Thumbnail erzeugen
  │
  ├──► Smart Search
  │
  ├──► Gesichtserkennung
  │
  └──► weitere Hintergrundjobs

Bei Videos kommen zusätzliche Aufgaben hinzu:

Video
  │
  ▼
Metadaten
  │
  ▼
Thumbnail
  │
  ▼
Transcoding

Diese Hintergrundjobs werden über Worker verarbeitet. Dazu gehören unter anderem Thumbnail-Erzeugung, Metadatenextraktion, Video-Transcoding, Smart Search und Gesichtserkennung.

Bei einem einzelnen Foto ist das kaum bemerkbar.

Bei 100.000 Bildern sieht die Situation völlig anders aus.

Hardware-Empfehlungen

Immich nennt aktuell folgende Mindest- und Empfehlungswerte:

RAM:
Minimum        6 GB
Empfohlen      8 GB

CPU:
Minimum        2 Kerne
Empfohlen      4 Kerne

Für eine kleine private Bibliothek sind diese Werte durchaus realistisch.

Wer jedoch:

• viele Benutzer,
• hunderttausende Medien,
• umfangreiche Videobestände,
• Smart Search,
• Gesichtserkennung,
• OCR,
• Video-Transcoding

gleichzeitig nutzt, sollte mehr Reserven einplanen.

Eine praxisnahe Hardware-Einteilung

Für eine kleine Installation:

CPU        4 Kerne
RAM        8 GB
Storage    SSD
GPU        optional

Für eine mittlere Installation:

CPU        6–8 Kerne
RAM        16 GB
Storage    NVMe + HDD/NAS
GPU        sinnvoll

Für ein großes Archiv:

CPU        8–16 Kerne
RAM        32 GB oder mehr
Storage    NVMe + großer Massenspeicher
GPU        empfehlenswert
Netzwerk   2,5 oder 10 Gbit/s

Diese Werte sind keine offiziellen Mindestanforderungen, sondern sinnvolle Planungsgrößen für größere Installationen.

SSD oder HDD?

Eine der wichtigsten Performance-Fragen lautet:

Welche Daten gehören auf SSD und welche können auf HDD liegen?

Die Antwort lautet:

Nicht alle Daten brauchen denselben Speichertyp.

PostgreSQL gehört auf SSD

Die PostgreSQL-Datenbank führt sehr viele kleine Lese- und Schreiboperationen durch.

Eine klassische Festplatte besitzt dabei wesentlich höhere Latenzen als eine SSD.

Deshalb sollte PostgreSQL möglichst auf:

SSD

oder besser:

NVMe

liegen.

Besonders profitieren davon:

• Timeline
• Suche
• Alben
• Benutzerverwaltung
• Metadatenzugriffe
• Smart-Search-Abfragen

Eine langsame Datenbank kann die gesamte Immich-Oberfläche ausbremsen.

Originalfotos dürfen auf HDD liegen

Originalbilder werden wesentlich seltener gelesen als Datenbankinformationen oder Vorschaubilder.

Deshalb können große Archive problemlos auf günstigeren Festplatten gespeichert werden.

Eine sinnvolle Aufteilung ist:

NVMe SSD
│
├── PostgreSQL
├── Immich-System
└── häufig verwendete Daten

HDD / NAS
│
└── Originalfotos und Videos

Damit wird schneller Speicher dort eingesetzt, wo er den größten Nutzen bringt.

Vorschaubilder auf SSD

Beim Scrollen durch die Timeline lädt Immich normalerweise nicht jedes vollständige Originalbild.

Stattdessen werden Vorschaubilder verwendet.

Bei einer Bibliothek mit:

200.000 Medien

werden solche Dateien sehr häufig gelesen.

Darum kann es einen deutlichen Unterschied machen, wenn Thumbnails und ähnliche häufig benötigte Daten auf SSD-Speicher liegen.

HDD als Flaschenhals

Bei einem großen Erstimport kann eine klassische HDD schnell zum limitierenden Faktor werden.

Immich liest gleichzeitig:

• Originalbilder
• EXIF-Daten
• Videos

und schreibt:

• Thumbnails
• Vorschaubilder
• transkodierte Dateien

Wenn zusätzlich PostgreSQL auf derselben HDD liegt, konkurrieren alle Dienste um denselben Datenträger.

Ungünstig:

eine HDD
│
├── PostgreSQL
├── Originalbilder
├── Thumbnails
├── Docker
└── Swap

Besser:

NVMe
├── PostgreSQL
├── Docker
└── schnelle Immich-Daten

HDD / NAS
└── Originalmedien

RAM – wie viel braucht Immich?

Immich empfiehlt aktuell mindestens 6 GB und bevorzugt 8 GB RAM.

Mit zunehmender Bibliotheksgröße wird zusätzlicher RAM jedoch sehr hilfreich.

Ein größerer Arbeitsspeicher hilft insbesondere:

• PostgreSQL
• Docker
• Dateisystem-Cache
• Machine Learning
• parallelen Hintergrundjobs

Für eine komfortable Installation halte ich:

16 GB

für einen sehr guten Ausgangspunkt.

Machine Learning braucht zusätzlichen RAM

Machine-Learning-Modelle müssen in den Speicher geladen werden.

Wer gleichzeitig:

• Smart Search
• Gesichtserkennung
• OCR

verwendet, benötigt entsprechend mehr Arbeitsspeicher.

Außerdem können mehrere Machine-Learning-Worker Modelle mehrfach in den Speicher laden.

Immich warnt deshalb davor, die Zahl der ML-Worker unnötig zu erhöhen, wenn nicht ausreichend RAM vorhanden ist.

Nicht sofort Docker-Speicherlimits setzen

Docker ermöglicht Speichergrenzen für Container.

Beispielsweise:

mem_limit: 4g

Das kann sinnvoll sein, birgt aber auch Risiken.

Wird das Limit zu niedrig angesetzt, kann Docker beziehungsweise der Kernel einen Prozess wegen Speichermangel beenden.

Immich weist darauf hin, dass aggressive RAM-Limits Instabilität verursachen können.

Für einen dedizierten Immich-Server ist deshalb häufig sinnvoller:

ausreichend RAM
+
vernünftige Job-Concurrency

statt:

sehr harte Container-Limits

CPU – mehr Kerne helfen nicht immer

Immich profitiert durchaus von mehreren CPU-Kernen.

Besonders CPU-lastig sind:

• Video-Transcoding
• Machine Learning
• Smart Search
• Gesichtserkennung
• Thumbnail-Generierung

Die Belastung ist beim erstmaligen Import besonders hoch.

Mehr CPU-Kerne ermöglichen mehr parallele Verarbeitung.

Aber:

Parallelität ist nicht automatisch Geschwindigkeit.

Der häufigste Fehler: zu hohe Parallelität

Immich besitzt Job-Concurrency-Einstellungen.

Damit lässt sich festlegen, wie viele Aufgaben gleichzeitig verarbeitet werden.

Beispielsweise:

Thumbnail Generation     4
Smart Search             4
Face Detection           4
Transcoding              4

Das sieht zunächst schnell aus.

Auf einem Vierkern-System bedeutet es aber möglicherweise:

16 konkurrierende Jobs

und damit:

• hohe CPU-Last
• viel RAM-Verbrauch
• massive I/O-Last
• schlechte Reaktionszeit

Die Immich-Dokumentation weist darauf hin, dass auf normalen Systemen bereits 2 bis 3 parallele ML-Jobs die CPU auslasten können.

Concurrency lieber schrittweise erhöhen

Ein sinnvolles Vorgehen:

1 Job
  ↓
System beobachten
  ↓
2 Jobs
  ↓
System beobachten
  ↓
3 Jobs

Dabei kontrollieren:

htop

und:

docker stats

Zusätzlich sollte die Job-Seite in Immich beobachtet werden.

Weniger Parallelität kann schneller sein

Das klingt zunächst widersprüchlich.

Angenommen:

8 parallele Jobs

überlasten:

• CPU
• Datenträger
• RAM

Dann entstehen Wartezeiten.

Mit:

3 parallelen Jobs

läuft jeder Job möglicherweise schneller und das Gesamtsystem reagiert deutlich besser.

Performance bedeutet deshalb:

Den optimalen Punkt finden – nicht einfach alle Regler auf Maximum stellen.

CPU-Last beim Video-Transcoding

Video-Transcoding gehört zu den rechenintensivsten Aufgaben.

Ein 4K-Video kann einen Prozessor erheblich belasten.

Immich ermöglicht deshalb, die Zahl der Threads für das Video-Transcoding einzustellen.

Auf schwächeren Systemen kann beispielsweise:

Threads: 1 oder 2

sinnvoll sein.

Immich empfiehlt dies ausdrücklich als Möglichkeit, CPU- und RAM-Belastung zu reduzieren.

Hardware-Transcoding nutzen

Eine wesentlich effizientere Lösung ist Hardware-Transcoding.

Immich unterstützt entsprechende Hardwarebeschleunigung über verschiedene Plattformen.

Je nach Hardware kommen beispielsweise infrage:

Intel Quick Sync
NVIDIA NVENC
VAAPI

Die genaue Unterstützung hängt von der Plattform ab.

Hardware-Transcoding wird über eine zusätzliche Compose-Konfiguration eingerichtet und anschließend in den Video-Transcoding-Einstellungen aktiviert.

Intel-GPU kann völlig ausreichen

Für einen privaten Immich-Server muss nicht zwingend eine große dedizierte Grafikkarte vorhanden sein.

Viele Intel-Prozessoren besitzen integrierte Grafikeinheiten.

Mit:

Intel Quick Sync

können Videos oft sehr effizient verarbeitet werden.

Dadurch bleibt die eigentliche CPU wesentlich stärker für andere Aufgaben verfügbar.

GPU für Machine Learning

Eine GPU kann bei Immich vor allem zwei Bereiche beschleunigen:

Machine Learning
Video-Transcoding

Für Machine Learning unterstützt Immich aktuell unter anderem:

• CUDA für NVIDIA
• ROCm für AMD
• OpenVINO für Intel-GPUs
• ARM NN für Mali
• RKNN für bestimmte Rockchip-SoCs

NVIDIA CUDA

Für NVIDIA-GPUs wird CUDA verwendet.

Aktuell verlangt Immich dabei unter anderem:

Compute Capability >= 5.2

sowie einen ausreichend aktuellen NVIDIA-Treiber.

Unter Linux wird zusätzlich das NVIDIA Container Toolkit benötigt.

Eine NVIDIA-GPU kann die Verarbeitung großer Bibliotheken erheblich beschleunigen.

Besonders:

Smart Search
Face Detection

profitieren davon.

Intel OpenVINO

Wer eine moderne Intel-CPU beziehungsweise Intel-GPU besitzt, kann OpenVINO verwenden.

Das ist interessant für:

• Intel Iris Xe
• Intel Arc
• kompatible integrierte Grafik

Damit lassen sich Machine-Learning-Aufgaben auf der GPU ausführen.

Immich weist allerdings darauf hin, dass OpenVINO mehr RAM verbrauchen kann als reine CPU-Verarbeitung.

AMD ROCm

Für AMD-GPUs unterstützt Immich ROCm.

Dabei muss allerdings geprüft werden, ob die verwendete GPU offiziell von ROCm unterstützt wird.

Außerdem ist das ROCm-Container-Image vergleichsweise groß und benötigt aktuell mindestens etwa:

35 GB freien Speicher

Machine Learning auf separaten Server auslagern

Eine besonders interessante Möglichkeit ist Remote Machine Learning.

Dabei läuft:

immich-machine-learning

nicht auf dem Immich-Hauptserver, sondern auf einem separaten Rechner.

Beispielsweise:

Immich-Server
CPU: sparsam
RAM: 16 GB

        │ Netzwerk
        ▼

KI-Server
GPU: NVIDIA
RAM: 32 GB

Immich unterstützt ausdrücklich einen separaten Machine-Learning-Server.

Wann Remote Machine Learning sinnvoll ist

Besonders interessant ist das bei:

• sehr großen Bibliotheken
• vorhandenem Gaming-PC
• separatem KI-Server
• energieeffizientem Immich-Host
• leistungsstarker GPU in einem zweiten System

Dadurch kann der eigentliche Immich-Server klein bleiben.

GPU bringt vor allem Durchsatz

Ein wichtiger Unterschied:

GPU-Beschleunigung sorgt hauptsächlich dafür, dass viele Machine-Learning-Jobs schneller abgearbeitet werden.

Bei einem Erstimport von:

100.000 Fotos

ist das ein enormer Vorteil.

Eine einzelne Smart-Search-Abfrage muss dadurch aber nicht proportional schneller werden.

Immich unterscheidet ausdrücklich zwischen höherem Durchsatz bei ML-Jobs und geringerer Suchlatenz.

Job-Concurrency mit GPU erhöhen

Mit einer leistungsfähigen GPU kann die Machine-Learning-Concurrency erhöht werden.

Beispielsweise:

CPU:
Concurrency 1–3

GPU:
Concurrency 4–8

Die optimalen Werte hängen von:

• GPU
• VRAM
• Modell
• Storage
• CPU

ab.

Immich empfiehlt, auch mit GPU nicht übermäßig hohe Concurrency-Werte zu verwenden; in der Dokumentation wird für normale Szenarien von Werten über 16 abgeraten.

Multi-GPU

Immich unterstützt inzwischen sogar mehrere GPUs für Machine Learning.

Dazu können beispielsweise:

MACHINE_LEARNING_DEVICE_IDS=0,1
MACHINE_LEARNING_WORKERS=2

verwendet werden.

Dann arbeitet jeweils ein Worker mit einer GPU.

Für typische Heiminstallationen ist das natürlich überdimensioniert.

Bei sehr großen Beständen kann es aber interessant sein.

Vorsicht beim VRAM

Mehr parallele ML-Jobs benötigen nicht nur Rechenleistung, sondern auch:

VRAM

Zu hohe Concurrency kann deshalb dazu führen, dass der Grafikspeicher ausgeht.

Das Resultat:

• Fehler
• Container-Abstürze
• langsamer Fallback
• instabile Verarbeitung

Auch hier gilt:

Langsam erhöhen und beobachten.

Machine-Learning-Modelle anpassen

Immich ermöglicht verschiedene Modelle für bestimmte ML-Funktionen.

Bei der Gesichtserkennung kann ein kleineres Modell weniger Ressourcen benötigen.

Immich nennt beispielsweise:

buffalo_s

als ressourcenschonendere Alternative zu:

buffalo_l

Die kleinere Variante kann auf schwächeren Systemen sinnvoll sein.

Machine-Learning-Modelle vorladen

Machine-Learning-Modelle werden bei Bedarf geladen.

Bei ausreichend RAM können Modelle auch vorgeladen werden.

Das kann verhindern, dass die erste Anfrage warten muss, während ein Modell zunächst geladen wird.

Immich stellt dafür verschiedene:

MACHINE_LEARNING_PRELOAD_...

Umgebungsvariablen bereit.

Das lohnt sich besonders auf Systemen, die dauerhaft genügend freien RAM besitzen.

Docker-Optimierung

Docker selbst verursacht normalerweise keinen dramatischen Performanceverlust.

Probleme entstehen häufiger durch:

• langsame Storage-Mounts
• falsche Ressourcenlimits
• zu viele parallele Jobs
• langsame Netzwerkfreigaben
• falsche GPU-Konfiguration

Docker auf SSD

Das Docker-Datenverzeichnis sollte möglichst auf SSD liegen.

Ungünstig:

Docker
PostgreSQL
Thumbnails
Originale

alles auf einer langsamen USB-HDD

Besser:

SSD / NVMe
├── Docker
├── PostgreSQL
└── häufig verwendete Daten

HDD / NAS
└── Medien

Keine Datenbank auf Netzwerkfreigaben

PostgreSQL sollte nicht auf:

SMB

oder:

NFS

betrieben werden.

Netzwerklatenzen und Dateisystembesonderheiten können die Datenbank massiv beeinträchtigen.

Der Datenbankbereich sollte lokal auf SSD/NVMe liegen. Diese Empfehlung passt auch zu den aktuellen Immich-Anforderungen und der bisherigen Architektur unserer Serie.

Docker Logs kontrollieren

Performanceprobleme können sich auch in Logs zeigen.

Beispielsweise:

docker compose logs -f immich-server

oder:

docker compose logs -f immich-machine-learning

Interessant sind:

• wiederholte Fehler
• Timeouts
• Speicherprobleme
• GPU-Probleme
• Modell-Ladefehler

Datenbank-Tuning

PostgreSQL ist eine der wichtigsten Komponenten für die gefühlte Geschwindigkeit.

Allerdings sollte man PostgreSQL nicht ohne Grund mit zahlreichen manuellen Parametern verändern.

In vielen privaten Installationen ist der größte Performancegewinn zunächst wesentlich einfacher erreichbar:

SSD
+
genug RAM
+
geringe Latenz

Erst wenn die Datenbank nachweislich der Flaschenhals ist, lohnt sich tieferes Tuning.

Was bei PostgreSQL wichtig ist

Besonders entscheidend sind:

• schneller Datenträger
• ausreichend RAM
• geringe I/O-Latenz
• genügend freier Speicher
• regelmäßige Wartung
• keine Netzwerkfreigabe

PostgreSQL nutzt außerdem den Betriebssystem-Cache.

Zusätzlicher RAM kommt deshalb indirekt auch Datenbankzugriffen zugute.

Datenbank nicht blind optimieren

Parameter wie:

shared_buffers
work_mem
maintenance_work_mem
effective_cache_size

können PostgreSQL beeinflussen.

Aber falsche Werte können das System auch verschlechtern.

Beispielsweise gilt:

work_mem

nicht einmal pro Server, sondern kann für viele Operationen parallel benötigt werden.

Ein extrem hoher Wert kann dadurch plötzlich mehrere Gigabyte RAM verbrauchen.

Deshalb:

Erst messen, dann optimieren.

Thumbnail-Generierung

Thumbnail-Erzeugung gehört ebenfalls zu den Hintergrundjobs von Immich.

Beim ersten Import werden Vorschaubilder für sehr viele Assets erzeugt.

Das erzeugt gleichzeitig:

CPU-Last
+
Lesezugriffe
+
Schreibzugriffe

Bei:

100.000 Fotos

kann dieser Prozess entsprechend lange dauern.

Thumbnail-Jobs reduzieren

Auf schwachen Systemen kann die Concurrency der Thumbnail-Jobs reduziert werden.

Beispielsweise:

4

auf:

1 oder 2

Dadurch dauert die Erstverarbeitung länger.

Die Weboberfläche und andere Dienste bleiben dafür wesentlich reaktionsfähiger.

Thumbnail-Speicher optimieren

Wenn die Originalbilder auf einem NAS liegen, aber die Thumbnails lokal auf SSD gespeichert werden, entsteht eine interessante Kombination:

NAS
└── große Originalbilder

NVMe
└── schnelle Vorschaubilder

Beim normalen Durchscrollen durch die Timeline müssen dadurch nicht ständig große Dateien über das Netzwerk gelesen werden.

NAS und Netzwerk

Bei externen Bibliotheken kann das Netzwerk zum Flaschenhals werden.

Ein Gigabit-Netzwerk liefert theoretisch:

125 MB/s

In der Praxis meist weniger.

Für eine normale Nutzung reicht das häufig völlig aus.

Beim Erstimport mehrerer Terabyte können:

2,5 Gbit/s

oder:

10 Gbit/s

deutlich schneller sein.

Netzwerk-Latenz ist ebenso wichtig

Nicht nur Bandbreite zählt.

100.000 kleine Dateien erzeugen sehr viele einzelne Zugriffe.

Ein System mit:

niedriger Latenz

kann deshalb trotz gleicher nomineller Bandbreite deutlich schneller wirken.

Monitoring gehört zur Optimierung

Ohne Messwerte ist Performance-Tuning meistens Raten.

Hilfreiche Linux-Werkzeuge sind:

htop

für CPU und RAM.

docker stats

für Containerressourcen.

iostat

für Datenträger.

iotop

für I/O-intensive Prozesse.

Und bei NVIDIA:

nvidia-smi

für GPU und VRAM.

GPU-Auslastung überprüfen

Immich empfiehlt zur Kontrolle der Hardwarebeschleunigung unter anderem Werkzeuge wie:

nvtop
intel_gpu_top
radeontop

Zusätzlich können die Logs des Machine-Learning-Containers geprüft werden.

Bei CUDA sollte beispielsweise erkennbar sein, dass ein entsprechender GPU-Execution-Provider verwendet wird.

Job-Queues beobachten

Unter:

Administration
→ Jobs

lässt sich kontrollieren:

• welche Jobs laufen,
• wie viele warten,
• ob Fehler auftreten.

Die Job-Seite ist deshalb eines der wichtigsten Werkzeuge für Performanceanalysen.

Beispiel: CPU ist dauerhaft bei 100 Prozent

Angenommen:

CPU: 100 %
RAM: 50 %
SSD: 20 %
GPU: nicht vorhanden

Dann sind wahrscheinlich:

Machine Learning
Video-Transcoding

die größten Kandidaten.

Mögliche Maßnahmen:

Concurrency reduzieren
Video-Threads reduzieren
Hardwarebeschleunigung aktivieren
ML auf separaten Server verschieben

Beispiel: CPU niedrig, System trotzdem langsam

Angenommen:

CPU: 30 %
RAM: 60 %
Disk: 100 %

Dann bringt eine schnellere CPU wahrscheinlich wenig.

Das Problem liegt eher beim:

Storage

Mögliche Lösung:

PostgreSQL auf NVMe
Thumbnails auf SSD
Originale weiterhin HDD

Beispiel: RAM permanent voll

Wenn:

RAM 98 %
Swap aktiv

ist, kann Immich sehr langsam werden.

Machine-Learning-Modelle, PostgreSQL und Docker konkurrieren dann um Speicher.

Mögliche Maßnahmen:

mehr RAM
weniger ML-Worker
kleinere ML-Modelle
geringere Job-Concurrency

Beispiel: Nur der Erstimport ist langsam

Das ist häufig völlig normal.

Der erste Import ist der mit Abstand belastendste Zustand.

Immich muss gleichzeitig:

Dateien entdecken
Metadaten lesen
Thumbnails erzeugen
Videos transkodieren
Smart Search berechnen
Gesichter erkennen

Die offizielle FAQ bezeichnet den initialen Backup-/Importvorgang ausdrücklich als besonders ressourcenintensiv.

Wenn anschließend alle Queues abgearbeitet wurden, fällt die Last im Alltag meist drastisch.

API und Worker trennen

Für größere Installationen bietet Immich außerdem die Möglichkeit, API- und Hintergrundworker auf getrennte Container beziehungsweise Dienste aufzuteilen.

Beispielsweise:

immich-server
      │
      └── API

immich-microservices
      │
      └── Hintergrundjobs

Die offizielle Dokumentation beschreibt dafür entsprechende Worker-Filter über:

IMMICH_WORKERS_INCLUDE

und:

IMMICH_WORKERS_EXCLUDE

Damit kann die Weboberfläche auch bei hoher Hintergrundlast besser von Verarbeitungstasks getrennt werden.

Für kleine Installationen ist dieser zusätzliche Aufwand normalerweise nicht erforderlich.

Eine optimierte Immich-Architektur

Für ein großes privates Archiv könnte eine sehr leistungsfähige Architektur so aussehen:

                         Netzwerk
                            │
             ┌──────────────┴──────────────┐
             │                             │
             ▼                             ▼
           NAS                         Immich
       HDD / RAID                     Server
             │                             │
      Originalmedien                       ├── NVMe
             │                             │   ├── PostgreSQL
             └────────── 10 GbE ───────────┤   ├── Docker
                                           │   └── Thumbnails
                                           │
                                           ├── 32 GB RAM
                                           │
                                           ├── 8 CPU-Kerne
                                           │
                                           └── GPU
                                               │
                                               ▼
                                        Machine Learning

Damit werden die unterschiedlichen Speicher- und Rechenanforderungen sauber voneinander getrennt.

Preis-Leistungs-Konfiguration

Für viele Privatanwender reicht deutlich weniger.

Ein sehr guter Sweet Spot wäre beispielsweise:

CPU:
moderner 4–8-Kern-Prozessor

RAM:
16 GB

System:
500 GB NVMe

Originalfotos:
große HDD oder NAS

Netzwerk:
1–2,5 Gbit/s

GPU:
Intel iGPU oder kleine NVIDIA-GPU

Damit lässt sich bereits eine sehr umfangreiche private Fotobibliothek komfortabel betreiben.

Eine GPU ist kein Muss

Immich funktioniert vollständig ohne dedizierte GPU.

Für kleine oder mittlere Bibliotheken reicht CPU-Verarbeitung durchaus aus.

Eine GPU wird besonders attraktiv bei:

sehr vielen Fotos
häufigen Imports
großen Videobeständen
Smart Search
Gesichtserkennung

Der größte Unterschied zeigt sich häufig beim erstmaligen Einlesen einer großen Sammlung.

Die sinnvollste Reihenfolge beim Optimieren

Bevor Geld für neue Hardware ausgegeben wird, sollte schrittweise analysiert werden.

Schritt 1

CPU, RAM und Storage messen

Schritt 2

Job-Queues kontrollieren

Schritt 3

PostgreSQL auf SSD prüfen

Schritt 4

Concurrency anpassen

Schritt 5

Video-Threads reduzieren

Schritt 6

Hardware-Transcoding aktivieren

Schritt 7

Machine Learning beschleunigen

Schritt 8

bei Bedarf Hardware aufrüsten

Damit wird verhindert, dass beispielsweise eine teure CPU gekauft wird, obwohl eigentlich eine langsame Festplatte das Problem verursacht.

Best Practices für schnelle Immich-Systeme

PostgreSQL auf SSD oder NVMe betreiben.

Originalmedien dürfen auf HDD oder NAS liegen.

Thumbnails möglichst auf schnellem Speicher halten.

Mindestens 8 GB RAM, für größere Installationen eher 16 GB oder mehr einplanen.

Job-Concurrency nicht unnötig hoch einstellen.

CPU-Last bei Video-Transcoding begrenzen.

Hardware-Transcoding nutzen, wenn möglich.

Machine Learning bei großen Bibliotheken per GPU beschleunigen.

ML bei Bedarf auf separaten Rechner auslagern.

Docker nicht mit zu engen RAM-Limits betreiben.

NAS möglichst kabelgebunden anbinden.

Performance immer messen, bevor Hardware gekauft wird.

Immich benötigt keinen High-End-Server.

Bereits ein moderner Vierkern-Prozessor, 8 bis 16 GB RAM und eine SSD ermöglichen eine sehr gute Grundlage.

Mit zunehmender Bibliotheksgröße wird allerdings die Architektur immer wichtiger.

Der größte Performancegewinn entsteht häufig nicht durch einen einzelnen besonders schnellen Prozessor, sondern durch die richtige Aufteilung:

NVMe
→ PostgreSQL und häufig verwendete Daten

HDD / NAS
→ Originalfotos und Videos

CPU
→ allgemeine Verarbeitung

GPU
→ Machine Learning und Video-Transcoding

RAM
→ Datenbank, Caches und ML-Modelle

Besonders beim ersten Import sollte man sich von hoher CPU-Last und langen Job-Warteschlangen nicht irritieren lassen. Dieser Vorgang ist wesentlich aufwendiger als der spätere Alltagsbetrieb.

Die wichtigste Regel beim Performance-Tuning lautet deshalb:

Nicht blind mehr Leistung hinzufügen – zuerst herausfinden, wo der eigentliche Flaschenhals liegt.

Mit SSD beziehungsweise NVMe für PostgreSQL, sinnvoll konfigurierten Job-Queues, genügend RAM und optionaler GPU-Beschleunigung kann Immich auch Bibliotheken mit hunderttausenden Fotos ausgesprochen komfortabel verwalten.

Im nächsten Teil unserer Serie beschäftigen wir uns mit Sicherheit und Datenschutz. Wir zeigen, wie Immich mit HTTPS, Reverse Proxy, Benutzerrechten, Updates, Netzwerksegmentierung und weiteren Maßnahmen gegen unbefugte Zugriffe abgesichert werden kann.