Immich på en hemmaserver med flera appar: Så påverkar delade resurser resultaten
Immich-resultat förändras på en server med flera appar eftersom containrar delar på begränsad CPU-, minnes-, lagrings- och nätverkskapacitet, trots separata processgränser.
En fotosökning kan vara snabb vid lunchtid och långsam under en annan applikations säkerhetskopiering, skanning eller omkodning. Immich-konfigurationen ändrades inte, men den tillgängliga resursbudgeten och cacheinnehållet gjorde det. Därför måste en användbar förklaring omfatta hela värdsystemets arbetsbelastning.
Containrar separerar processer, inte fysisk kapacitet
Containrar tillhandahåller namnrymder och kontrollerbara begränsningar, men körs i slutänden på samma processorer och använder vanligtvis samma minnesstyrenhet, diskar och nätverksgränssnitt. En Immich-tjänst kan hålla sig inom sin egen gräns och ändå behöva vänta på orelaterat arbete vid en gemensam fysisk enhet eller i kärnans schemaläggare.
En fält rapport om Immich i flera containrar beskriver en strömsnål värd som kör dussintals containrar med vanligtvis måttlig CPU-användning. Det garanterar inte samma resultat på andra system; det visar varför antalet tjänster ensamt är svaga bevis och varför det faktiska överlappande arbetet måste observeras på värdnivå.
Inventera alla schemalagda och plötsliga arbetsbelastningar i omgivningen: säkerhetskopieringar, medieskanningar, nedladdningar, databaser och videoomkodningar. Anteckna deras starttider tillsammans med Immichs svarstid. Korrelationssamband bevisar inte orsakssamband, men återkommande överensstämmelse identifierar ett kontrollerat paus- eller omplaneringsexperiment som kan testa den misstänkta störningen.
Konkurrens om minnet förändrar vilka data som finns i cachen
Immich fungerar bättre när ofta använda databassidor, miniatyrbilder och modelldata finns kvar i minnet. En närliggande tjänst som utökar sin arbetsmängd kan tränga undan dessa sidor utan att orsaka ett slut-på-minne-fel. Nästa begäran måste då läsa från lagringen eller ladda modellen, vilket medför kostnader som saknades när datan var varm.
Kingstons diskussion om serverminne förklarar att tillräcklig kapacitet minskar beroendet av långsammare lagring för minnesintensiva applikationer. Tillämpat här är poängen inte att varje hemmaserver behöver företagsminne, utan att förlorad cache kan omvandla en till synes identisk Immich-begäran till en annan fysisk arbetsbelastning.
Jämför aktivitet i sidcache, växlingsutrymme, större sidfel och lagringsläsningar före och efter att den närliggande tjänsten startar. Om en paus återställer beteendet för varma begäranden utan att Immich ändras, tyder det på att minnesresidens spelar in. En hög total RAM-procent räcker inte som indikator, eftersom fungerande filsystemscache avsiktligt använder annars ledigt minne.
Lagringsköer kopplar samman orelaterade tjänster
En säkerhetskopiering kan strömma stora filer medan Immich utför små databas- och miniatyrbildsoperationer. Även när den sammanlagda bandbredden ligger under en disks angivna maximala hastighet kan köbildning öka slutförandetiden för fördröjningskänsliga begäranden. Nätverksansluten lagring lägger dessutom till ytterligare en schemaläggare och nätverksväg i samma kedja av konkurrens.
ZimaSpaces artikel om Immichs datasökväg visar att val av sökresultat och visning av media är separata steg med olika beroenden. Den skillnaden hjälper till att identifiera kopplingar till lagringen: snabba resultatidentifierare följda av fördröjda miniatyrbilder pekar längre fram i sökvägen än när själva databasurvalet är långsamt.
Mät enhetsfördröjning och ködjup per monteringspunkt medan samma begäran återskapas. Pausa endast den misstänkta I/O-tunga tjänsten och upprepa sedan efter att cacharna har stabiliserats. Om förbättringen kvarstår under flera alternerande körningar är det motiverat att separera schemaläggning eller lagring. Om inte, återgå till hypoteser om CPU, minne eller nätverk.
Använd ett isoleringstest med paus och uppspelning
Välj en fast slutpunkt, till exempel att läsa in samma tidslinjefönster eller köra en känd smart sökning, och definiera kalla eller varma förhållanden. Genomför tre körningar med hela tjänstemixen. Pausa sedan en möjlig störande tjänst utan att starta om Immich och upprepa samma klientsekvens och observationsfönster.
En rapport om att Immich konkurrerade kraftigt under bearbetning efter en uppdatering beskriver en annan fototjänst som misslyckades med uppladdningar medan värdsystemet var upptaget. Det gäller en viss konfiguration och är ingen universell begränsning, men visar att en fungerande bakgrundskö ändå kan förbruka tillräckligt mycket delad kapacitet för att försämra en annan interaktiv tjänst.
Acceptera störning som orsak först när pausen ger en upprepningsbar förändring i svarstiden och den relevanta resursens väntetid minskar samtidigt. Testa därefter en begränsad åtgärd – lägre samtidighet, ett schemalagt tidsfönster, CPU-kvot, minnesreservation eller separat lagring. Behåll inställningar för återställning, eftersom isolering av en störande tjänst kan blottlägga en andra begränsning.
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.
