Waardoor worden zoek- of queryresultaten in Immich trager naarmate de hoeveelheid data toeneemt?

Zoeken in Immich wordt trager naarmate de bibliotheek groeit, wanneer grotere indexen en actieve datasets de efficiënte cache-, filter- of opslagwerking overschrijden—not simply because photos exist.

Een grotere bibliotheek vergroot meerdere hoeveelheden tegelijk: rijen, embeddings, metadata, miniaturen en mogelijke filtercombinaties. Stel vast welke fase trager wordt, want snellere bestandsopslag kan een gebrekkig querypad niet repareren, terwijl databaseoptimalisatie een externe miniatuurkoppeling niet kan versnellen.

Groei breidt meer uit dan alleen de oorspronkelijke bibliotheek

Elk toegevoegd object kan databaserijen, geëxtraheerde metadata, zoekrepresentaties, gezichten, miniaturen en gecodeerde media opleveren. Deze structuren groeien in verschillende mate en worden op verschillende manieren benaderd. Terabytes aan oorspronkelijk bibliotheekmateriaal kunnen de zoektijd daarom niet voorspellen zonder te weten hoeveel doorzoekbare entiteiten en afgeleide objecten het verzoek doorloopt.

De analyse van het Immich-datapad van ZimaSpace maakt onderscheid tussen achtergrondverwerking, doorzoekbare representaties, databaseselectie en geleverde media. De praktische les voor querydiagnose is dat groei van de bibliotheek zowel de doorzoekbare catalogus als de bestanden die na een resultaat worden gepresenteerd verandert, waardoor meer dan één vertraging kan ontstaan.

Leg bij elke mijlpaal het aantal objecten, de databasegrootte, de omvang van de vectorindex, de miniatuurvoetafdruk en de kardinaliteit van veelgebruikte filters vast. Een tijdreeks laat zien welke structuur samen met de latentie groeit en voorkomt dat een niet-gerelateerde toename van originele videobytes ten onrechte wordt verantwoordelijk gehouden voor de databaseselectietijd.

Vectorindexen worden gevoeliger voor geheugenpassing

Semantisch zoeken doorloopt een representatie-index in plaats van elke originele afbeelding te lezen. Naarmate die index groeit, blijven de actieve graaf of pagina's mogelijk niet langer volledig in het geheugen. Willekeurige cachemissers veranderen werk op geheugensnelheid dan in opslagreads, waardoor de staartlatentie sterker stijgt dan het gemiddelde CPU-gebruik doet vermoeden.

Een technische analyse van vectorzoeken in PostgreSQL legt uit dat HNSW-prestaties kunnen verslechteren wanneer de actieve graaf groter wordt dan het geheugen, omdat traversering met willekeurige toegang gevoelig wordt voor cachemissers. Immich-versies en indeximplementaties kunnen veranderen, dus gebruik dit als een mechanisme om te testen en niet als een configuratievoorschrift.

Meet een vaste semantische zoekopdracht na een herstart, na één opwarmronde en nadat je niet-gerelateerde delen van de bibliotheek hebt aangeraakt. Vergelijk databaselezingen, cache-hitgedrag en apparaatlatentie. Sterke winst na opwarmen die verdwijnt wanneer de actieve dataset breder wordt, ondersteunt de hypothese van onvoldoende geheugenpassing; gelijkmatig trage zoekopdrachten wijzen ergens anders op.

Filters en queryplannen kunnen veranderen met de kardinaliteit

Datum, persoon, eigenaar, album en andere voorwaarden veranderen hoeveel kandidaten vóór of tijdens het rangschikken overblijven. Naarmate de gegevensverdeling verandert, kan hetzelfde zichtbare filter een veel groter deel van de bibliotheek selecteren. Databasestatistieken en plankeuzes kunnen daarom belangrijk zijn, zelfs wanneer de zoekterm zelf ongewijzigd blijft.

Een overzicht van de beperkingen van pgvector merkt op dat het combineren van vectorzoeken met metadatafilters lastig kan zijn en dat vectorwerklasten CPU, geheugen en I/O van PostgreSQL delen met transactioneel werk. Het artikel biedt algemene PostgreSQL-informatie en ondersteunt dus het mechanisme, maar bewijst niet hoe één Immich-queryplan werkt.

Maak vergelijkbare zoekopdrachten met en zonder één filter, met bekende resultaatsets. Leg de verwerkingstijd aan de serverzijde en databaseactiviteit vast, niet alleen het moment waarop de browser klaar is. Als de selectietijd groeit terwijl geretourneerde miniaturen snel verschijnen, richt je dan op plannen, statistieken, indexpassing en conflicterende belasting in plaats van op mediaopslag.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Scheid resultaatselectie van resultaatweergave

De interface kan traag aanvoelen nadat de database al overeenkomende object-ID's heeft geselecteerd. Voor de weergave zijn nog steeds het ophalen van miniaturen, opslaglezingen, het overbrengen van de respons en decodering op de client nodig. Een groeiende boom met afgeleide bestanden of een externe koppeling kan deze tweede fase vertragen, terwijl de eigenlijke zoekquery gezond blijft.

Een rapport over een grote import beschrijft brede traagheid in Immich terwijl honderdduizenden metadata- en miniatuurtaken nog in de wachtrij stonden. Dit toont overlappende achtergrondbelasting aan, geen universele schaalbeperking, en laat zien waarom groeitests zowel met actieve wachtrijen als nadat deze zijn leeggelopen moeten worden uitgevoerd.

Gebruik browsertiming of API-waarnemingen om het voltooien van de resultaatrespons afzonderlijk te markeren van het moment waarop de laatste zichtbare miniatuur verschijnt. Herhaal een bekende zoekopdracht terwijl wachtrijen gepauzeerd zijn en daarna terwijl ze actief zijn. Als ID's traag verschijnen, onderzoek dan database- en indexpaden; als alleen afbeeldingen traag zijn, controleer dan miniatuuropslag, netwerklevering, decodering op de client en concurrerende I/O op de achtergrond.