Hoe Immich zoekindexering inplant tijdens grote imports van mobiele bibliotheken

Tijdens een grote import vanuit een mobiele bibliotheek kan Immich assets sneller accepteren dan alle zoekgerelateerde achtergrondtaken kunnen worden afgerond. Daardoor kan de zoekindex achterlopen op het voltooien van uploads.

Die vertraging is alleen een planningsprobleem wanneer de vereiste taken wachten, worden uitgevoerd of concurreren om gedeelde resources; het is niet automatisch een zoekfout. Het nuttige model is een pijplijn: binnenkomende assets creëren werk, wachtrijen vangen pieken op, workers verwerken die wachtrijen en de database ontvangt de resultaten waarop latere zoekopdrachten vertrouwen.

Grote imports creëren een piek van verschillende taken

Een migratie vanaf een mobiel apparaat doet meer dan alleen bytes kopiëren. Elke geaccepteerde asset kan vervolgwerk creëren voor miniaturen, metadata, videobewerking, slim zoeken, gezichtsherkenning of andere ingeschakelde functies. Omdat deze taken verschillende kosten en afhankelijkheden hebben, kan één import meerdere achterstanden creëren met verschillende verwerkingssnelheden.

Het verzoek om opeenvolgende taken laat zien waarom gebruikers dit gedrag op beperkte hosts opmerken: beheerders willen soms dat zware activiteiten één voor één worden uitgevoerd in plaats van elkaar te overlappen. Dat verzoek wijst op concurrentie om resources, maar bewijst niet dat opeenvolgende uitvoering voor elke server de beste keuze is.

Meet elke wachtrij aan de hand van binnenkomsten, voltooide taken en fouten, in plaats van het totale aantal wachtende taken als één werklast te behandelen. Een grote achterstand met miniaturen kan ander afhankelijk werk anders vertragen dan een achterstand met videotranscodering, en een wachtrij die gestaag kleiner wordt heeft een andere betekenis dan een wachtrij die dezelfde items telkens opnieuw probeert.

Prioriteit voor wachtrijen is niet hetzelfde als globale resourcecontrole

Een systeem kan bepaald werk prioriteit geven of pauzeren, terwijl andere taaktypen nog actief zijn. Daarom garandeert een importtool die één soort achtergrondactiviteit vermindert niet automatisch een inactieve CPU, stille schijven of direct actuele zoekresultaten. Planningsbeleid en het totale resourcegebruik houden verband met elkaar, maar zijn niet identiek.

Een release van immich-go introduceerde gepauzeerde achtergrondtaken tijdens uploads om conflicten te beperken. Dat gedrag hoort bij die importer en versie en mag daarom niet worden veralgemeniseerd tot de bewering dat elke mobiele Immich-import automatisch hetzelfde werk pauzeert.

De praktische grens is waarneembare voortgang. Als uploads snel doorgaan terwijl zoekgerelateerde wachtrijen bewust zijn gepauzeerd, worden nieuwe assets vanzelf pas later doorzoekbaar. Als de wachtrij is ingeschakeld maar het aantal voltooide taken vrijwel nul blijft, verschuift de vraag van planningsbeleid naar een fout in een worker, resource of specifieke asset.

Concurrency kan de doorvoer verhogen en de responsiviteit verslechteren

Meer gelijktijdige workers kunnen het aantal voltooide taken per minuut verhogen totdat een gedeelde afhankelijkheid verzadigd raakt. Daarna kan extra parallellisme leiden tot meer wachttijd in de database, hogere opslaglatentie, geheugendruk of meer contextwisselingen. Daardoor kan het systeem achtergrondwerk gemiddeld sneller afronden, terwijl interactieve verzoeken een langere staartlatentie krijgen.

Een praktijkrapport over vastgelopen taakwachtrijen beschrijft een grote bibliotheek waarbij het verlagen van de concurrency de waargenomen voortgang verbeterde. Dat is een implementatiespecifieke observatie, maar het laat zien waarom concurrency als een variabele van de werklast moet worden getest en niet als een vaste indicator van servercapaciteit moet worden beschouwd.

Gebruik een bekende zoekopdracht voor een al geïndexeerd album als interactieve controle. Als die zoekopdracht snel blijft terwijl de dekking van nieuwe foto's achterloopt, is de import voornamelijk een probleem van actualiteit. Als zelfs oude zoekopdrachten trager worden terwijl de CPU-, opslag- of databasewachttijd toeneemt, verbruikt het planningsvenster interactieve capaciteit.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Een groeiende wachtrij is niet automatisch een fout

Een achterstand groeit telkens wanneer er sneller werk binnenkomt dan workers het kunnen voltooien. Tijdens een geplande historische import is dat gedurende enige tijd te verwachten. Het foutsignaal is niet de maximale lengte van de wachtrij zelf, maar de combinatie van stilgevallen voltooiing, terugkerende fouten of een achterstand die niet afneemt nadat er geen nieuwe taken meer binnenkomen.

Discussies over grote imports, zoals deze migratie van 200.000 foto's, laten zien hoe beheerders uploadsnelheid onderscheiden van verwerking achteraf. Ervaringen uit de community zijn nuttig om te bepalen wat je moet meten, maar mogen niet worden omgezet in een universele tijdsinschatting voor een andere bibliotheek.

Dit mechanisme verklaart ontbrekende zoekresultaten niet meer wanneer de relevante taak is voltooid en dezelfde geautoriseerde gebruiker nog steeds een bekende asset niet kan vinden. Controleer dan de zoekrelevantie, filters, machtigingen, het modelgedrag of de verwerking van de specifieke asset, in plaats van de concurrency van de import verder af te stemmen.

Voer een planningstest met twee banen uit

Maak één vaste baan voor oude, geïndexeerde inhoud en één baan voor een kleine nieuwe import. Noteer vóór de import de responstijd van een bekende oude zoekopdracht. Noteer tijdens de import met regelmatige tussenpozen diezelfde zoekopdracht, de uploadsnelheid, aantallen wachtende en voltooide taken, fouten, CPU-druk, geheugendruk en opslaglatentie.

Gebruik de analyse van ZimaSpace over het Immich-datapad om de overdrachts-, verwerkings-, opslag- en zoekfasen van elkaar te onderscheiden. Een knelpunt is pas bruikbaar voor actie wanneer het overeenkomt met de fase waarin de beoogde service daadwerkelijk niet wordt gehaald.

Accepteer de planning wanneer oude zoekopdrachten binnen de tolerantie van je huishouden blijven, wachtrijen voor nieuwe items taken blijven voltooien en de achterstand afneemt nadat er geen nieuwe taken meer binnenkomen. Verminder of verplan achtergrondconcurrency alleen wanneer de gecontroleerde test laat zien dat dezelfde gedeelde resource zowel interactief gebruik als de voortgang van de wachtrij vertraagt.