Hur Immich schemalägger sökindexering under stora importer av mobilbibliotek
Under en stor import från ett mobilbibliotek kan Immich ta emot resurser snabbare än alla sökrelaterade bakgrundsjobb hinner slutföras, så sökindexets aktualitet kan släpa efter att uppladdningen är klar.
Den fördröjningen är bara ett schemaläggningsproblem när de nödvändiga jobben väntar, körs eller konkurrerar om delade resurser; det är inte automatiskt ett sökfel. Den användbara modellen är en pipeline: inkommande resurser skapar arbete, köer absorberar toppar, arbetare tömmer köerna och databasen tar emot resultaten som senare sökningar är beroende av.
Stora importer skapar flera olika jobbtoppar
En mobil migrering innebär mer än att bara kopiera data. Varje mottagen resurs kan skapa efterföljande arbete för miniatyrbilder, metadata, videohantering, smart sökning, ansikten eller andra aktiverade funktioner. Eftersom dessa jobb har olika kostnader och beroenden kan en enda import skapa flera köer med olika tömningstakt.
Begäran om sekventiella jobb visar varför användare märker detta på begränsad hårdvara: administratörer vill ibland att tunga aktiviteter ska köras en i taget i stället för samtidigt. Begäran är ett tecken på resurskonkurrens, inte ett bevis på att sekventiell körning är bäst för alla servrar.
Mät varje kö utifrån inkommande jobb, slutföranden och fel i stället för att behandla det totala antalet väntande jobb som en enda arbetsmängd. En stor kö med miniatyrbilder kan fördröja annat beroende arbete på ett annat sätt än en kö med videotranskodning, och en kö som stadigt minskar betyder något annat än en kö som upprepade gånger försöker behandla samma objekt.
Köprioritet är inte samma sak som global resurskontroll
Ett system kan prioritera eller pausa utvalt arbete och ändå ha andra jobbtyper aktiva. Därför garanterar inte ett importverktyg som minskar en typ av bakgrundsaktivitet nödvändigtvis en ledig processor, lugna diskar eller omedelbart aktuella sökresultat. Schemaläggningspolicy och total resursförbrukning hänger ihop, men är inte identiska.
En version av immich-go införde pausade bakgrundsjobb under uppladdningar för att minska konflikter. Det beteendet hör till just den importören och versionen och bör därför inte generaliseras till påståendet att alla mobila Immich-importer automatiskt pausar samma arbete.
Den praktiska gränsen är observerbara framsteg. Om uppladdningarna fortsätter snabbt medan sökrelaterade köer medvetet är pausade blir nya resurser naturligt sökbara först senare. Om kön är aktiverad men antalet slutföranden förblir nära noll ändras frågan från schemaläggningspolicy till fel hos arbetare, resurser eller specifika resurser.
Samtidighet kan öka genomströmningen och försämra svarstiden
Fler samtidiga arbetare kan öka antalet slutförda jobb per minut tills ett delat beroende blir överbelastat. Därefter kan ytterligare parallellism öka väntetiden på databasen, lagringslatensen, minnesbelastningen eller kontextväxlingen. Systemet kan då i genomsnitt slutföra bakgrundsarbete snabbare, samtidigt som interaktiva förfrågningar får längre svarstider i svansänden.
En praktisk rapport om hängande jobbköer beskriver ett stort bibliotek där minskad samtidighet förbättrade de observerade framstegen. Det är en distributionsspecifik observation, men visar varför samtidighet bör testas som en arbetsbelastningsvariabel i stället för att behandlas som ett fast mått på serverns kapacitet.
Använd en känd sökning efter ett redan indexerat album som interaktiv kontroll. Om den sökningen förblir snabb medan täckningen av nya foton släpar efter är importen främst ett aktualitetsproblem. Om även gamla sökningar blir långsammare samtidigt som väntetiden ökar för processor, lagring eller databas, förbrukar schemaläggningsfönstret det interaktiva utrymmet.
En växande kö är inte automatiskt ett fel
En eftersläpning växer när arbete anländer snabbare än arbetarna hinner slutföra det. Under en avsiktlig historisk import är det förväntat under en viss period. Felindikationen är inte själva toppstorleken på kön, utan kombinationen av avstannade slutföranden, upprepade fel eller en eftersläpning som inte töms efter att nya jobb slutat anlända.
Diskussioner om stora importer, som denna migrering av 200 000 foton, visar hur administratörer skiljer på uppladdningsgenomströmning och efterföljande bearbetning. Erfarenheter från communityn är användbara för att identifiera vad som bör mätas, men bör inte omvandlas till en universell tidsuppskattning för ett annat bibliotek.
Den här mekanismen slutar förklara saknade sökresultat när det relevanta jobbet har slutförts och samma behöriga användare fortfarande inte kan hämta en känd resurs. Då bör du granska sökrelevans, filter, behörigheter, modellbeteende eller resurspecifik bearbetning i stället för att fortsätta finjustera importens samtidighet.
Genomför ett schemaläggningstest med två spår
Skapa ett fast spår för gammalt, indexerat innehåll och ett annat för en liten ny import. Före importen registrerar du svarstiden för en känd gammal sökning. Under importen registrerar du samma sökning, uppladdningstakt, antal väntande och slutförda jobb, fel, processorbelastning, minnesbelastning och lagringslatens med regelbundna intervall.
Använd ZimaSpaces analys av Immichs datapipeline för att hålla överföring, bearbetning, lagring och sökning åtskilda. En flaskhals är bara åtgärdbar när den sammanfaller med det steg vars servicemål faktiskt inte uppfylls.
Acceptera schemat när gamla sökningar håller sig inom hushållets tolerans, köerna för nya objekt fortsätter att slutföras och eftersläpningen töms efter att nya jobb slutat anlända. Minska eller schemalägg om bakgrundssamtidigheten först när det kontrollerade testet visar att samma delade resurs fördröjer både interaktiv användning och köernas 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.
