Hoeveel RAM en opslag heeft Immich echt nodig?

Hoeveel RAM heeft Immich nodig?

Immich vraagt om 6 GB RAM (random access memory) als gedocumenteerd minimum en 8 GB als aanbeveling, op 2 CPU-cores aan de onderkant en 4 voor een comfortabele installatie. Dat cijfer dekt de gehele stack, omdat Immich uit vier containers bestaat in plaats van één applicatie. Het doorbladeren van een reeds geïmporteerde bibliotheek is licht qua belasting. Het geheugenverbruik vindt plaats tijdens het importeren, en het grootste deel daarvan wordt verbruikt door één container die u kunt uitschakelen.

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

Dit zijn de gepubliceerde cijfers van de Immich-vereistenpagina per oktober 2026. Het is een aanbeveling voor de dimensionering, geen controle die de software uitvoert bij het opstarten. Dezelfde pagina documenteert één kleinere configuratie, 4 GB met uitgeschakelde machine learning-functies, en niets daaronder. Wat verandert op een kleinere server is welke achtergrondtaken worden voltooid, en wat een import doet wanneer het geheugen opraakt.

Er bestaat één echte harde limiet. Sinds versie 3 heeft de machine learning-container op amd64-hosts een x86-64-v2 CPU nodig, wat de meeste processors dekt die sinds ongeveer 2012 zijn verkocht. De vereiste is van toepassing op die container, niet op de server zelf. Op oudere hardware kunt u dus machine learning uitschakelen, het op een andere machine draaien zoals hieronder beschreven, of op v2.7.5 blijven, wat volgens de Immich-documentatie de laatste compatibele versie is.

Als de installatie nog moet plaatsvinden, begin dan met de volledige Immich-installatie op een VPS met Docker Compose en keer hier terug om de server te dimensioneren.

Waar het geheugen blijft: vier containers

Het officiële Compose-bestand start vier services. Elke service heeft een ander geheugenprofiel, waardoor één totaalcijfer de relevante details verbergt.

immich-server bedient de webinterface en de API, en voert tevens de achtergrondtaken uit. Twee workers bevinden zich in die ene container. api beantwoordt verzoeken van de browser en de mobiele app. microservices beheert de wachtrijen, inclusief het genereren van miniaturen en videocodering. De variabelen IMMICH_WORKERS_INCLUDE en IMMICH_WORKERS_EXCLUDE splitsen deze twee in afzonderlijke containers; op deze manier kunt u de intensieve helft een eigen geheugenlimiet geven zonder de helft die uw foto's serveert te beperken.

database is een PostgreSQL 14-image met de ingebouwde VectorChord-extensie. Deze bevat alle metadata en één zoekvector per asset. De documentatie van Immich geeft deze service als enige een expliciete ondergrens in de stack: als u Docker-resourcebeperkingen toepast, heeft de database minimaal 2 GB nodig. Dezelfde pagina stelt dat de database idealiter op lokale SSD-opslag moet staan en nooit op een netwerkshare, omdat vector- en index-lookups kleine willekeurige leesacties zijn. Een netwerkvolume verandert elke actie in een round-trip. Als een keuze voor een abonnement hiervan afhangt, is het verschil tussen NVMe- en SATA SSD-opslag op een VPS hier belangrijker dan waar dan ook in deze stack.

redis draait de Valkey-image en beheert de wachtrijen voor taken. Dit is met grote afstand de kleinste van de vier, omdat het taakrecords opslaat in plaats van fotogegevens.

immich-machine-learning is de service die de grootte van uw abonnement bepaalt. Deze laadt modellen voor slim zoeken, gezichtsherkenning en tekstherkenning; een geladen model blijft in het geheugen aanwezig. MACHINE_LEARNING_MODEL_TTL staat standaard op 300, waardoor een model na vijf minuten zonder verzoeken wordt verwijderd en bij het volgende verzoek opnieuw wordt ingelezen vanaf het /cache-volume. Tijdens een bulkimport is er nooit een pauze van vijf minuten, waardoor de modellen vanaf de eerste tot de laatste asset geladen blijven.

Wat verandert er tijdens een import

Een inactieve Immich-instantie is stil. Imports zijn het moment waarop kleine servers bezwijken, omdat het uploaden van één asset een keten van taken in de wachtrij plaatst en er meerdere wachtrijen tegelijkertijd draaien.

Het extraheren van metadata leest de bestandsheader en is licht. Het genereren van thumbnails is zwaarder. Immich produceert drie thumbnail-outputs per asset: een wazige thumbhash-placeholder, een WebP-preview en een JPEG-thumbnail, plus nog een extra thumbnail voor elk gedetecteerd gezicht. Elk van deze taken decodeert een afbeelding, en de taak-concurrency bepaalt hoeveel er tegelijkertijd worden gedecodeerd. Concurrency is de vermenigvuldiger die de geringe kosten per taak omzet in een belasting voor de gehele server; daarom noemt de Immich FAQ dit als het eerste wat u moet verlagen op een systeem met beperkte middelen. Stel de concurrency voor de zware wachtrijen in op 1 onder Administration, Settings, Job Settings.

Video-assets voegen transcodering toe. Elke transcode-taak is een afzonderlijk FFmpeg-proces met eigen geheugengebruik, en het zal elke CPU-thread gebruiken die u toestaat.

Smart search stuurt elke nieuwe asset naar de machine learning-container om één embedding-vector te berekenen. Gezichtsdetectie voert een tweede model uit over dezelfde afbeelding. Bij de eerste import van een bestaande fotobibliotheek draaien beide wachtrijen urenlang over elke asset die u bezit. Dat is het meest kritieke moment voor het geheugengebruik van de gehele installatie, en dit gebeurt slechts één keer.

Waarom gezichts- en objectherkenning het meeste RAM vereisen

Het verwerken van gezichten bestaat uit twee taken. Gezichtsdetectie voert een model uit in de machine learning-container en bepaalt de kaders. Gezichtsherkenning groepeert deze detecties vervolgens in personen, waarbij deze stap de vectorindex in Postgres bevraagt. Een grote bibliotheek belast beide services na elkaar: de modelcontainer tijdens de detectie, en de database tijdens het groeperen.

Vier instellingen bepalen wat de machine learning-container in het geheugen houdt.

• Het gezichtsmodel. Immich levert standaard buffalo_l mee, en de FAQ adviseert buffalo_s voor een kleine server. Dit is een kleiner model, waardoor het minder geheugen inneemt en sneller draait, ten koste van de nauwkeurigheid bij kleine of zijwaartse gezichten.
• Het aantal workers. MACHINE_LEARNING_WORKERS staat standaard op 1. Elke worker is een afzonderlijk proces dat zijn eigen kopie van de modellen laadt; het verhogen naar 2 verdubbelt dus ruwweg het resident geheugengebruik van de modellen. Laat dit op 1 staan, tenzij u RAM over heeft.
• De batchgrootte. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION begrenst hoeveel gezichten er tegelijk worden verwerkt. Een batch wordt in zijn geheel in het geheugen gehouden, dus een groepsfoto met veertig gezichten kost meer geheugen dan een portret.
• Welke modeltypen überhaupt actief zijn. Slim zoeken, gezichtsdetectie en tekstherkenning laden elk hun eigen modellen. Door de functies die u niet gebruikt uit te schakelen onder Administration, Settings, Machine Learning Settings, wordt het geheugengebruik hiervan permanent verwijderd in plaats van alleen tussen imports door.

Er is ook MACHINE_LEARNING_MODEL_ARENA, gedocumenteerd als het vooraf toewijzen van CPU-geheugen om fragmentatie te voorkomen; dit staat standaard aan. Wijzig dit als laatste. Het effect hangt af van de onderliggende geheugenallocator, dus de enige betrouwbare manier om dit te beoordelen is door docker stats voor en na de wijziging te monitoren.

Drie werkende profielen: 2 GB, 4 GB en 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"
  }
]

Beschouw deze waarden als limieten om in te voeren in Compose, niet als metingen van wat Immich daadwerkelijk verbruikt. Een limiet is een bovengrens. Het reserveert niets en maakt een service niet kleiner. Het bepaalt welke service de kernel beëindigt wanneer het systeem zonder geheugen komt te zitten; een beslissing die u beter zelf kunt nemen dan de kernel op basis van eigen scores.

De 2 GB-server: verwijder de machine learning-container

2 GB ligt onder het gedocumenteerde minimum van 6 GB en onder de enige door Immich gedocumenteerde gereduceerde setup, namelijk 4 GB met machine learning uitgeschakeld. Immich publiceert geen 2 GB-configuratie, dus dit profiel is een niet-ondersteund compromis, geen recept. Als u het toch probeert, becommentarieer dan de volledige immich-machine-learning-service in docker-compose.yml, of laat deze draaien en schakel elk model uit onder Administration, Settings, Machine Learning Settings. Het verwijderen van de container is de betere optie, omdat een uitgeschakeld model nog steeds een Python-proces in het geheugen achterlaat.

U behoudt uploads, albums, delen, mobiele back-up, miniaturen en zoeken op datum, locatie en bestandsnaam. U verliest het zoeken op beschrijving, het automatisch groeperen van gezichten in personen en tekstherkenning in afbeeldingen.

De vier limieten tellen op tot ongeveer 1,7 GB, wat de host ongeveer 300 MB overlaat. De documentatie van Immich stelt dat de database alleen al minimaal 2 GB nodig heeft zodra Docker-resourcelimieten worden gebruikt, wat de gehele server beslaat. Dus 768 MB voor de database ligt ruim onder die ondergrens, en daarom is Postgres de service die hier het meest waarschijnlijk wordt beëindigd.

Wat als eerste faalt, is het importeren. Het serveren van een pagina is een metadata-query plus een bestandlezing, dus het bladeren door een bestaande bibliotheek vraagt het minste van de server, maar een import met veel video's zal leiden tot swapping, omdat een transcode- en thumbnail-wachtrij op hetzelfde moment geheugen vereisen. Als 2 GB alles is wat u heeft, stel dan elke zware wachtrij in op concurrency 1 en voeg een swap-bestand toe. Als u een plan kiest, beschouw 4 GB dan als de werkelijke ondergrens.

De 4 GB-server: machine learning aan, één taak tegelijk

Immich documenteert 4 GB als werkbaar met machine learning-functies uitgeschakeld, en dat is de enige gereduceerde configuratie op de vereistenpagina. Met de database op de gedocumenteerde ondergrens van 2 GB, tellen de drie limieten in de tabel op tot ongeveer 3,2 GB, wat de host ongeveer 800 MB overlaat. Stel de taak-concurrency in op 1 voor het genereren van miniaturen en houd het aantal transcode-threads laag.

Om gezichts- en objectherkenning te behouden, is de gedocumenteerde route om de machine learning-container op een andere machine te draaien, zoals hieronder beschreven, en deze server daarnaar te laten verwijzen. Het draaien op dezelfde 4 GB-server gaat voorbij aan wat Immich documenteert, omdat de database-ondergrens ongeveer 2 GB overlaat voor de server, Redis, de modellen en de host samen. Als u het toch probeert, beperk de machine learning-container dan met een Compose-limiet, schakel gezichtsherkenning naar buffalo_s en stel de taak-concurrency in op 1 voor het genereren van miniaturen, gezichtsdetectie en slim zoeken.

De eerste scan van een bestaande bibliotheek zal vele uren duren, en bij een grote bibliotheek meer dan een dag. Dat is eerder een CPU-limiet dan een geheugenlimiet, dus meer RAM zal dit niet verkorten.

Als machine learning op deze server draait, is het eerste wat faalt die container tijdens de eerste bulk-scan. Zonder limiet groeit deze terwijl een transcode-taak ook groeit, en de kernel beëindigt de grootste van de twee. Omdat deze binnen enkele seconden herstart, toont docker ps -a deze als Up met een uptime die veel korter is dan die van zijn buren in plaats van Exited (137), en de wachtrij loopt stilletjes verder achter dan toen u voor het laatst keek.

De 8 GB-server: de gedocumenteerde aanbeveling

8 GB met 4 cores komt overeen met wat Immich aanbeveelt, en alles draait op de standaardinstellingen: slim zoeken, gezichtsdetectie, tekstherkenning en transcoding, op standaard concurrency. Bibliotheken met meer dan honderdduizend assets draaien hier comfortabel, en de druk verschuift van geheugen naar schijfsnelheid, omdat de vectorindex en de metadata-query's zijn wat de database de hele dag doet.

Stel de limieten alsnog in. Op een server met ruimte voorkomen de limieten dat één vastgelopen wachtrij de database mee omlaag trekt. Als u dit vergelijkt met de kleinere opties, maakt wat een VPS werkelijk kost per geheugencategorie het 8 GB-plan meestal de goedkoopste manier om niet meer te hoeven finetunen.

Geheugenlimieten per service instellen met Compose

Bewerk docker-compose.yml hiervoor niet. Dat bestand wordt bij elke upgrade overschreven door wget. Plaats de limieten in docker-compose.override.yml ernaast, wat docker compose automatisch samenvoegt.

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 zou nu uw limiet in de kolom MEM USAGE / LIMIT moeten tonen in plaats van het totale geheugen van de host. Als de kolom met limieten nog steeds de volledige grootte van de host aangeeft, is het override-bestand niet geladen: controleer de bestandsnaam en voer docker compose config uit om het samengevoegde resultaat te bekijken.

Houd de database op 2048M of hoger. Immich specificeert 2 GB als de ondergrens voor de database wanneer Docker-resourcebeperkingen worden gebruikt. Een te lage limiet verandert een trage service in een niet-werkende service; verhoog deze dus als een container in een opstartlus terechtkomt. Meer informatie over de werking vindt u in geheugenlimieten per service instellen in Docker Compose, inclusief waarom deploy buiten Swarm werkt met Compose v2.

De machine learning-container uitschakelen of verplaatsen

Op een kleine server is het verplaatsen van deze container naar een andere machine de meest effectieve wijziging die u kunt doorvoeren. Immich ondersteunt het draaien van deze container op een andere host. Maak dit bestand aan op de tweede host, wat bijvoorbeeld een desktop kan zijn die alleen 's avonds aan staat:

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

Ga vervolgens in de webinterface naar Administration, Settings, Machine Learning Settings, klik op Add URL en voer http://<host>:3003 in. Houd de versie op beide hosts gelijk, aangezien de documentatie van Immich waarschuwt dat versieverschillen tussen de twee kunnen leiden tot bugs en instabiliteit.

Deze poort verstuurt afbeeldingsvoorbeelden van uw foto's onversleuteld naar de andere machine. De documentatie van Immich waarschuwt dat de machine learning-container zelf geen beveiligingsmaatregelen bevat. Houd deze daarom op een privénetwerk of laat het verkeer verlopen via een WireGuard-tunnel tussen de twee hosts. Stel poort 3003 nooit bloot aan het internet.

Als het hele concept van een actieve model-container het probleem vormt, is dat een valide reden om te vergelijken hoe PhotoPrism en Immich verschillen in hun achtergrondprocessen voordat u zich vastlegt op een bepaalde opslaggrootte.

Hoeveel schijfruimte heeft een Immich-bibliotheek nodig?

Er is geen eenduidige vermenigvuldiger, omdat vier verschillende factoren in verschillende mate groeien. Hieronder volgt de berekening voor een bibliotheek met 50.000 foto's en 500 korte video's.

[
  {
    "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
  }
]

De 200 GB aan foto's en 60 GB aan video zijn aannames. Vervang deze door uw eigen gemiddelden voordat u hardware aanschaft, aangezien video de doorslaggevende factor is: één minuut aan video van een telefoon is groter dan honderd foto's.

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}'

De rij van 39 GB is de enige gepubliceerde verhouding die Immich hanteert: gegenereerde thumbnails en getranscodeerde video voegen gemiddeld 10 tot 20 procent toe aan de omvang van de bibliotheek. Dit is een bereik omdat het afhangt van hoeveel van uw bestanden video's zijn die opnieuw moeten worden gecodeerd voor browsercompatibiliteit. Een bibliotheek met JPEGs valt aan de onderkant van dit bereik.

De database is 3 GB, wat nagenoeg een vaste waarde is. Immich documenteert databasebestanden doorgaans als 1 tot 3 GB, omdat deze metadata en zoekvectoren bevatten in plaats van pixels. De model-cache is 2 GB en groeit als u meerdere modellen inschakelt of verschillende modellen test. De FAQ markeert dit volume om precies die reden als een ruimteverbruiker.

De vijf rijen tellen op tot iets meer dan 300 GB, dus een volume van 500 GB biedt ruimte voor groei, terwijl een volume van 250 GB dat niet doet. Monitor de verdeling met:

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

Zes mappen bevinden zich onder UPLOAD_LOCATION. upload en library bevatten de originelen, thumbs bevat previews en gezichts-thumbnails, encoded-video bevat opnieuw gecodeerde kopieën, profile bevat avatars en backups bevat automatische database-dumps. Alleen upload, library en profile zijn onvervangbaar, aangezien al het overige daaruit opnieuw kan worden gegenereerd.

Twee zaken verrassen gebruikers vaak. Verwijderde bestanden gaan eerst naar de prullenbak en blijven ruimte innemen totdat de prullenbak wordt geleegd; een grote opschoonactie levert dus op de dag zelf geen extra ruimte op. Daarnaast bevat een database-dump alleen metadata en is deze waardeloos zonder de bijbehorende bestanden:

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

Combineer dit met een kopie op bestandsniveau van de originelen naar een locatie buiten de server, waarvoor restic-back-ups van een VPS naar externe opslag bedoeld zijn.

Transcoding wordt beperkt door de CPU, niet door het RAM

Het toevoegen van RAM zal transcoding niet versnellen. Immich gebruikt FFmpeg voor transcoding en op een standaard VPS wordt elk frame gedecodeerd en gecodeerd door de CPU. Elk FFmpeg-proces houdt buffers van gedecodeerde frames in het geheugen vast; daarom rekent de importsectie een transcode als een eigen geheugenkostenpost, maar de snelheid wordt bepaald door de CPU. Zelfs wanneer hardwareversnelling beschikbaar is, documenteert Immich dat standaard alleen het coderen wordt versneld. De CPU blijft dus decoderen en tone mapping uitvoeren, tenzij u ook hardware-decoding inschakelt.

Hardwareversnelling vereist het extra hwaccel.transcoding.yml Compose-bestand en een apparaat om door te geven, waarbij gebruik wordt gemaakt van NVENC, Quick Sync, RKMPP of VAAPI. De meeste VPS-abonnementen bieden geen van deze opties, dus houd rekening met de CPU.

De praktische instelling is het aantal threads. Onder Administration, Settings, Video Transcoding Settings betekent een thread-waarde van 0 dat alle cores worden gebruikt. Hierdoor kan één video de webinterface bevriezen op een abonnement met 2 cores. Stel deze waarde in op 1 of 2, zoals de Immich FAQ adviseert, zodat een transcode traag verloopt in plaats van verstorend werkt.

Waarom swap thrashing tijdens een import lijkt op een vastloper

Dit is de fout die het vaakst verkeerd wordt geïnterpreteerd. Wanneer Immich geen geheugen meer heeft, zijn er twee uitkomsten, en slechts één daarvan ziet eruit als een fout.

Zonder swap beëindigt de kernel een proces. De container herstart binnen enkele seconden, waardoor de takenwachtrij in de browser simpelweg stopt en vervolgens weer hervat. Het bewijs staat 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) betekent dat het proces werd beëindigd met signaal 9. 137 is 128 plus 9. U ziet deze status alleen terwijl de container is gestopt. Zodra het restart-beleid de container heeft teruggebracht, toont docker ps -a deze weer als Up, en een uptime die veel korter is dan die van de andere Immich-containers is de aanwijzing. Signaal 9 op zichzelf bewijst geen geheugenprobleem, omdat Docker dit ook verstuurt wanneer een normale stop de time-out overschrijdt. Een OOMKilled-waarde van true bevestigt dat het proces vanwege geheugengebrek werd beëindigd, en zodra de container is herstart, zijn de oom-kill-regels uit dmesg de betrouwbare bron.

Met swap wordt niets beëindigd en treden er geen fouten op. De kernel begint geheugenpagina's naar de schijf te verplaatsen, de import vertraagt met een factor tien, en de webinterface reageert niet meer binnen de normale time-out. Elke container draait nog. Elke health check kan nog steeds slagen. Het lijkt op een vastloper, en gebruikers herstarten op dit punt de server, waardoor de voortgang van de wachtrij verloren gaat en er niets verandert.

free -m
vmstat 1 5

Aanhoudende waarden die niet nul zijn in de kolommen si en so van vmstat betekenen dat de machine continu swap leest en schrijft; dit is de definitie van thrashing. De free -m-rij voor Swap-gebruik zal op hetzelfde moment stijgen.

Voeg hoe dan ook swap toe op een machine met 2 GB of 4 GB geheugen, want een trage import die u kunt diagnosticeren is beter dan een beëindigde container die u niet kunt herstellen:

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

Los daarna de oorzaak op. Verlaag de job concurrency naar 1, beperk de machine learning-container, of verplaats deze naar een andere host. Swap geeft u de tijd om dit te doen. Het is op zichzelf niet de oplossing.

FAQ

Kan ik Immich draaien op een 2 GB VPS?

Niet in een configuratie die door Immich wordt ondersteund. De vereistenpagina stelt 6 GB als minimum vast, noemt 4 GB met uitgeschakelde machine learning-functies als de enige kleinere opstelling, en geeft aan dat de database alleen al 2 GB nodig heeft zodra Docker-resourcebeperkingen worden gebruikt. Het uitcommentariëren van de immich-machine-learning-service en het instellen van de job-concurrency op 1 kan het werkend krijgen, maar dit is een niet-ondersteund compromis en Postgres is de service die het meest waarschijnlijk wordt beëindigd tijdens een import. Als u slechts 2 GB heeft, voeg dan een 2 GB swap-bestand toe zodat een import-piek de server vertraagt in plaats van een container te laten crashen. Als u een abonnement kiest, begin dan bij 4 GB.

Waarom stopt mijn Immich-import zonder foutmelding?

Twee verschillende oorzaken zien er vanuit de browser identiek uit. Ofwel een container werd beëindigd vanwege geheugengebrek en is al opnieuw opgestart, in welk geval docker ps -a deze toont als Up met een verdacht korte uptime (Exited (137) verschijnt alleen als u het treft terwijl het gestopt is), of de host is aan het swappen, in welk geval elke container nog steeds draait en alles simpelweg erg traag is. vmstat 1 5 onderscheidt deze: aanhoudende getallen die niet nul zijn in de kolommen si en so betekenen dat er wordt geswapt. Verlaag in beide gevallen de job-concurrency voor het genereren van thumbnails, gezichtsherkenning en slim zoeken.

Wat betekent exitcode 137 in de Immich-logs?

137 is 128 plus signaal 9, dus het proces werd beëindigd met SIGKILL. Op een Immich-server is dat meestal een geheugenlimiet, hetzij de eigen limiet van de container of de host die geen geheugen meer heeft, maar de code alleen bewijst dit niet: Docker stuurt ook SIGKILL wanneer een container niet binnen de time-out stopt, standaard 10 seconden op Linux. Controleer dit met docker inspect immich_machine_learning | grep -i oomkilled. Een waarde van true bevestigt dat de kernel het proces beëindigde vanwege geheugengebrek, en free -m plus sudo dmesg -T | grep -i oom-kill vertelt u vervolgens of het de containerlimiet was of de gehele host. De machine learning-container is meestal het slachtoffer omdat dit doorgaans het grootste proces is.

Hoeveel schijfruimte heeft Immich nodig per foto?

Houd rekening met het originele bestand plus 10 tot 20 procent. Immich documenteert dat gegenereerde thumbnails en getranscodeerde video de bibliotheekgrootte met gemiddeld 10 tot 20 procent vergroten, en de database zelf is doorgaans 1 tot 3 GB, zelfs voor een grote bibliotheek. Video bepaalt in feite uw totaal, dus meet uw eigen gemiddelde bestandsgrootte voordat u een abonnement kiest in plaats van een vermenigvuldiger toe te passen op een aantal foto's.

Heb ik een GPU nodig voor Immich?

Nee. Elk onderdeel van Immich draait op de CPU. Een grafische kaart versnelt model-inferentie in de machine learning-container en video-encodering, maar geen van beide is vereist. De meeste VPS-abonnementen bieden er geen aan. Stel op hardware die alleen op CPU draait de transcode-threads in op 1 of 2, gebruik het buffalo_s-gezichtsmodel en laat de eerste bulk-import 's nachts draaien.