Varför ökar Immichs bakgrundsarbete kraftigt efter en biblioteksändring?
Immichs bakgrundsarbete kan öka kraftigt efter en biblioteksändring eftersom en enskild filsystems- eller bibliotekshändelse kan förgrena sig till jobb för skanning, metadata, derivat och indexering.
Den viktiga skillnaden går mellan en avgränsad våg av förväntad ombearbetning och arbete som upprepade gånger går igenom samma resurser utan någon motsvarande ändring. En flytt av en mapp, en omskanning av ett externt bibliotek, nyupptäckta filer eller versionsspecifikt beteende kan alla ge liknande CPU- och ködiagram. Därför måste bibliotekshändelsen kopplas till exakt vilka jobb den skapade.
En biblioteksskanning är ett upptäcktssteg, inte hela arbetsbelastningen
En skanning börjar med att stämma av det Immich kan se på disken mot det som redan är känt om biblioteket. När en ny eller ändrad resurs upptäcks kan efterföljande resultat därför vara inaktuella eller saknas, vilket skapar ytterligare arbete efter att själva skanningen verkar vara klar.
En rapport från en användare om överlappande biblioteksskanningar beskriver hur en skanningskö blev klar medan köerna för miniatyrbilder, ansiktsigenkänning och annat fortfarande var kraftigt fyllda. Den viktiga mekanismen är förgrening: en kort upptäcktsfas kan skapa en mycket längre bearbetningssvans.
Läs köerna i beroendeordning. Om bibliotekskön går ner till noll medan köerna för härledda arbeten fortsätter att bearbetas, kan servern helt enkelt hålla på att konsumera jobb som skapades av den slutförda skanningen. Att kalla hela perioden för en upprepad skanning döljer vilket steg som faktiskt använder resurser.
Ändrade sökvägar kan se ut som arbete med nya resurser
Externa bibliotek är särskilt känsliga för ändringar i filsystemets identitet och sökvägar. När filer organiseras om kan programmet behöva stämma av deras nya platser mot det lagrade resursläget. Beroende på versionens och bibliotekstypens beteende kan detta utlösa mer arbete än antalet verkligt nya foton antyder.
En diskussion från 2026 om flyttade externa filer dokumenterar ett fall där omorganiserade sökvägar behandlades som nya resurser och ledde till nya miniatyrbilder, ML-analys och videobearbetning. Det är en rapport om en känd begränsning, inte ett löfte om att varje flytt av en mapp fungerar på samma sätt.
Detta förklarar varför en omorganisation av ett bibliotek kan bli mycket dyrare än att lägga till samma antal nya foton. Om filsökvägarna och innehållet däremot inte har ändrats, tyder upprepad fullständig generering på ett annat tillstånd som bör undersökas i stället för att accepteras som normalt bakgrundsbeteende.
Efterföljande köer kan växa medan arbetet slutförs
Antalet väntande jobb behöver inte minska monotont. När ett jobb slutförs kan det göra en resurs berättigad till ett annat jobb eller lägga till fler uppgifter i ett senare steg. Under en omfattande avstämning kan servern därför visa aktiv framdrift och samtidigt en växande efterföljande kö.
Diskussionen om en miniatyrbildskö noterar att nya jobb för miniatyrbilder kan dyka upp medan annan bearbetning slutförs. Den visar också en viktig gräns: historiska buggar och felkonfigurerade importsökvägar kan skapa patologiska loopar, så en växande kö måste tolkas utifrån version och sökväg.
Använd räknare för slutfört arbete och kontrollera nyligen skapade resultat manuellt, inte bara antalet väntande jobb. Om miniatyrbilder visas, antalet slutförda jobb ökar och takten så småningom överstiger antalet nya jobb, töms kön även om dess topp nås efter att den ursprungliga biblioteksskanningen har avslutats.
En ökning är onormal när arbetet saknar en motsvarande ändring
Förväntad bakgrundsbelastning bör kunna kopplas till en definierad händelse: nya resurser, en metadatauppdatering, en ändrad sökväg, en modelländring eller en uttrycklig åtgärd för att generera om resultat. Förklaringen blir svagare när samma gamla resurser schemaläggs upprepade gånger utan någon ändring av konfiguration eller innehåll.
En aktuell rapport där en skanning påverkade andra bibliotek verkade generera om arbete i flera externa bibliotek och visar varför omfattningen spelar roll. Betrakta sådana rapporter som versionsbunden evidens att jämföra med dina egna loggar, inte som normalt Immich-beteende.
Mekanismen förklarar inte heller en värd som förblir upptagen långt efter att de relevanta köerna är tomma. Kontrollera i så fall databasunderhåll, säkerhetskopior, en annan container, filsystemaktivitet eller en process som har hängt sig. En biblioteksändring bör inte bli en allmän förklaring till annan ihållande belastning.
Koppla ändringen till en jobböversikt före och efter
Innan en kontrollerad biblioteksändring registrerar du antalet resurser, antalet väntande och aktiva jobb för de viktigaste jobbtyperna, CPU-användningen, lagringens svarstid och tidpunkten för den senast slutförda skanningen. Lägg till eller flytta en liten, känd grupp, gör samma observation igen och notera exakt vilka köer som växer och hur snabbt de töms.
Använd ZimaSpaces förklaring av Immichs datasökväg för att hänföra varje ökning till upptäckt, bearbetning, databas eller lagring, i stället för att behandla all bakgrundsaktivitet som en enda kategori.
Acceptera ökningen när det genererade arbetet står i proportion till den kontrollerade ändringen, resultat visas, felen förblir begränsade och köerna återgår mot utgångsläget. Eskalera när oförändrade resurser genereras om upprepade gånger, omfattningen överstiger det redigerade biblioteket eller samma jobb misslyckas utan att göra framsteg.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Öppna modeller kommer ikapp den ledande AI:n – blir 2026 året då lokal AI blir tillräckligt bra?
Öppna modeller blir tillräckligt bra för fler lokala AI-arbetsbelastningar, medan avancerade molnmodeller fortfarande är användbara för de svåraste resonemangs- och agentuppgifterna.
NVIDIA PAIR förvandlar ditt hemnätverk till ett lokalt AI-kluster – behöver du fortfarande en enda stor GPU-server?
NVIDIA PAIR distribuerar lokala AI-förfrågningar över flera datorer, vilket gör beräkningskapaciteten mer elastisk samtidigt som en hems server kan hålla data och tillstånd beständiga.
Varför känns Immich snabbare på LAN än via fjärranslutningar?
LAN-förfrågningar tar vanligtvis en kortare väg med lägre latens. Fjärråtkomst innebär begränsningar i WAN-kapaciteten och kan lägga till DNS-, TLS-, proxy-, VPN- eller relähopp.
