Vad gör att Immichs sökningar eller frågeresultat blir långsammare när datamängden växer?
Immich-sökningar blir långsammare när större index och arbetsmängder överskrider effektiv cache-, filtrerings- eller lagringskapacitet – inte helt enkelt för att det finns fler foton.
Ett större bibliotek ökar flera mängder samtidigt: rader, embeddingar, metadata, miniatyrbilder och möjliga filterkombinationer. Diagnostisera vilket steg som går långsammare, eftersom snabbare fillagring inte kan åtgärda en dålig sökväg, medan databasjusteringar inte kan snabba upp en fjärransluten miniatyrbildsmontering.
Tillväxten omfattar mer än det ursprungliga biblioteket
Varje tillagd resurs kan bidra med databasrader, extraherad metadata, sökrepresentationer, ansikten, miniatyrbilder och kodad media. Dessa strukturer växer i olika takt och nås på olika sätt. Terabyte i originalbiblioteket kan därför inte förutsäga söklatens utan kunskap om hur många sökbara entiteter och härledda objekt som begäran går igenom.
ZimaSpaces analys av Immichs datasökväg skiljer mellan bakgrundsbehandling, sökbara representationer, databasurval och levererad media. Den praktiska lärdomen för sökdiagnostik är att bibliotekets tillväxt förändrar både den sökbara katalogen och filerna som visas efter ett resultat, vilket skapar mer än en möjlig fördröjning.
Registrera antalet resurser, databasstorlek, vektorindexets storlek, miniatyrbildsutrymme och kardinaliteten hos ofta använda filter vid varje milstolpe. En tidsserie visar vilken struktur som växer tillsammans med latensen och förhindrar att en orelaterad ökning av antalet byte i originalvideor får skulden för tiden det tar att välja data från databasen.
Vektorindex blir känsliga för om de får plats i minnet
Semantisk sökning går igenom ett representationsindex i stället för att läsa varje originalbild. När indexet växer kanske dess aktiva graf eller sidor inte längre kan ligga kvar i minnet. Slumpmässiga cachemissar omvandlar då arbete i minneshastighet till lagringsläsningar, vilket gör att svarstidens svans ökar kraftigare än den genomsnittliga CPU-användningen antyder.
En teknisk analys av PostgreSQL-vektorsökning förklarar att HNSW-prestanda kan försämras när den aktiva grafen växer ur minnet, eftersom genomgång med slumpmässig åtkomst blir känslig för cachemissar. Immich-versioner och indeximplementationer kan ändras, så använd detta som en mekanism att testa, inte som en konfigurationsföreskrift.
Mät en fast semantisk sökning efter omstart, efter en uppvärmning och efter att ha berört orelaterade delar av biblioteket. Jämför databasläsningar, cacheträffar och enhetens latens. Kraftiga uppvärmningsvinster som försvinner när arbetsmängden breddas stöder hypotesen om otillräcklig minnespassning; jämnt långsamma sökningar pekar åt ett annat håll.
Filter och frågeplaner kan förändras med kardinaliteten
Datum, person, ägare, album och andra villkor ändrar hur många kandidater som återstår före eller under rangordningen. När datadistributionen förändras kan samma synliga filter välja en mycket större andel av biblioteket. Databasstatistik och planval kan därför spela roll även när själva söktermen är oförändrad.
En genomgång av pgvectors begränsningar noterar att det kan vara svårt att kombinera vektorsökning med metadatafilter och att vektorarbetsbelastningar delar PostgreSQLs CPU, minne och I/O med transaktionsarbete. Artikeln innehåller generell PostgreSQL-evidens, så den stöder mekanismen snarare än bevisar en specifik Immich-frågeplan.
Skapa parade sökningar med och utan ett enskilt filter, med kända resultatmängder. Registrera tidsåtgången på serversidan och databasaktiviteten, inte bara när webbläsaren blir klar. Om urvalstiden ökar medan de returnerade miniatyrbilderna fortfarande visas snabbt bör du fokusera på planer, statistik, indexpassning och konkurrens om resurser i stället för medielagring.
Separera resultatval från resultatrendering
Gränssnittet kan kännas långsamt efter att databasen redan har valt matchande resursidentifierare. Rendering kräver fortfarande uppslagning av miniatyrbilder, lagringsläsningar, överföring av svar och avkodning på klienten. Ett växande träd av härledda filer eller en fjärransluten montering kan fördröja denna andra fas medan själva sökfrågan fortfarande fungerar bra.
En rapport från en stor import beskriver en omfattande långsamhet i Immich medan hundratusentals metadata- och miniatyrbildsjobb fortfarande låg i kö. Den visar överlappande bakgrundsbelastning, inte en universell skalningsgräns, och visar varför tillväxttester bör köras både medan köerna är aktiva och efter att de har tömts.
Använd webbläsarmätningar eller API-observationer för att markera när resultatsvaret är klart separat från när den sista synliga miniatyrbilden visas. Upprepa en känd sökning med köerna pausade och därefter aktiva. Om identifierarna blir långsammare bör du undersöka databas- och indexvägar; om bara bilderna blir långsammare bör du granska miniatyrbildslagring, nätverksleverans, klientavkodning och konkurrerande bakgrunds-I/O.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vad är Immichs tillstånd, och vilka delar måste bevaras?
Immich-tillståndet omfattar original, databasrelationer, identitet, konfiguration och härledda filer; bevara varje del utifrån om den kan återskapas.
Hur hanterar Immich autentisering för lokala och fjärranslutna sessioner?
Immich använder serverbaserad identitet med klientsessioner, medan proxyhuvuden, ursprung och OIDC-omdirigeringar kan göra att lokalt och på distans beter sig olika.
Varför beter sig Immich annorlunda efter en omstart av containern?
Efter en omstart av Immich är tillfällig cacheförlust förväntad; bestående ändringar av inloggning, databas eller media tyder på beroende- eller persistensfel.
