Hur många samtidiga uppgifter kan Immich hantera innan sökningen blir mindre responsiv?
Immich har inget universellt säkert antal uppgifter; sökningen försämras när samtidiga arbetare mättar den resurs som interaktiva förfrågningar också behöver.
Två servrar kan köra samma antal jobb för miniatyrer, metadata och maskininlärning men ändå få mycket olika söklatens. Den användbara gränsen är därför den högsta blandade arbetsbelastning som håller sig inom ett definierat mål för interaktiv svarstid samtidigt som kön fortfarande töms.
Ett antal uppgifter beskriver inte arbetsbelastningen
Ett samtidighetsvärde är endast ett tillåtet antal arbetare, inte ett direkt mått på belastning. Generering av miniatyrer, videotranskodning, metadataextrahering och inferens med maskininlärning utför olika mängder beräknings- och lagringsarbete. Fyra lätta metadatajobb kan lämna gränssnittet responsivt, medan två videojobb belastar samma värd betydligt mer.
En rapport från communityn om hög CPU-användning för maskininlärning beskriver hur man minskade antalet samtidiga jobb efter en stor import, vilket sänkte belastningen men förlängde slutförandetiden. Observationen stöder den centrala avvägningen: lägre samtidighet skyddar förgrundens responsivitet genom att låta eftersläpningen tömmas långsammare, inte genom att ta bort det underliggande arbetet.
Behandla varje kö som en arbetsbelastningsklass. Registrera vilka jobb som är aktiva, vilken medietyp de bearbetar och om maskinvaruacceleration är tillgänglig. En säker totalsiffra som härletts från små JPEG-bilder kan inte överföras till RAW-foton eller långa videor, eftersom arbetet som representeras av varje plats har förändrats.
Sökningen försämras vid den första gemensamma mättnadspunkten
Interaktiv sökning passerar flera gemensamma lager: förfrågan når applikationen, databasen väljer resultat, miniatyrer läses in och en klient visar dem. Bakgrundsarbetare kan konkurrera i mer än ett lager. Det första mättade lagret blir den praktiska samtidighetsgränsen även när varje container förblir frisk.
En Immich-diskussion om prestanda beskriver fördröjd inläsning av miniatyrer på en värd med tillräcklig nominell bandbredd, vilket visar varför länkhastigheten ensam inte kan identifiera flaskhalsen. CPU-schemaläggning, databasläsningar, filsystemslatens och leverans till klienten förblir möjliga orsaker tills mätningar visar vilken väntetid som ökar under den långsamma förfrågan.
Utnyttjandegrad måste kombineras med fördröjning. Hög CPU-användning med stabil söklatens kan vara produktiv mättnad, medan måttlig CPU-användning tillsammans med ökande diskväntan kan identifiera en lagringskö. Minnestryck är viktigt när återvinning eller växling till disk skapar fördröjning, inte enbart för att operativsystemet använder tillgängligt RAM som cache.
Sökbarheten kan släpa efter utan långsamma sökfrågor
En snabb fråga kan returnera en ofullständig sökbar samling när nya resurser ännu inte har slutfört sitt indexeringsarbete. Omvänt kan varje objekt redan vara indexerat medan frågorna är långsamma eftersom åtkomst till databas eller lagring är konkurrensutsatt. Att kalla båda förhållandena ”försämrad sökning” döljer två olika slutpunkter och leder till felaktig justering av samtidigheten.
ZimaSpaces förklaring av Immichs datasökväg skiljer mellan godkännande av uppladdning, färdiga förhandsvisningar och semantisk hämtning som separata slutpunkter. Den åtskillnaden är viktig under belastningstester: tidsstämpeln när en fil anländer kan inte ersätta tidsstämpeln när dess representation blir sökbar.
Följ två klockor för en fast importkohort. Den ena mäter interaktiv frågelatens mot redan indexerade kontrollfoton; den andra mäter tiden tills nyimporterade foton visas i förutbestämda sökningar. Den första skyddar den aktiva användarupplevelsen, medan den andra visar genomströmningskostnaden för att sänka samtidigheten.
Hitta gränsen med ett stegtest, inte en gissning
Skapa en representativ mediebatch och välj tre fasta sökningar som returnerar kända resurser. Börja med en arbetare i varje aktiv kö, kör importen och registrera medianen samt söklatensen i den långsamma svansen, tömningstakten för kön, CPU, minnestryck, nätverkstrafik och lagringens väntetid under samma observationsfönster.
Allmän vägledning om flaskhalsar rekommenderar att arbetsbelastningsförändringar kopplas till väntetider i CPU, minne, disk, nätverk och beroenden i stället för att välja det diagram som ser mest belastat ut. Öka endast en samtidighetskontroll per körning. Genom att upprepa samma söksekvens och använda samma mediekohort förblir den ändrade variabeln identifierbar.
Stoppa vid det första steget där målet för sökningens långsamma svans misslyckas, servern börjar växla till disk, lagringens väntetid förblir förhöjd, fel uppstår eller bakgrundskön slutar ge användbar genomströmning. Testa om föregående steg efter en kall omstart och igen när systemet är uppvärmt. Det lägre, upprepningsbara steget är den försvarbara gränsen för denna arbetsbelastning.
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.
Vad gör att Immichs sökningar eller frågeresultat blir långsammare när datamängden växer?
Immich-tillväxt kan göra index större, tränga undan ofta använda sidor, komplicera filter och fördröja mediedistributionen; separera dessa steg innan du finjusterar.
