Hur lagringslatens påverkar säkerhetskopiering av familjefoton i Immich

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How Storage Latency Changes Immich Family Photo Backup - Zima Store Online

Lagringslatens gör Immich långsammare när nödvändiga läsningar eller skrivningar väntar, särskilt när importer konkurrerar med databasaktivitet och surfning på delade enheter.

Två telefoner säkerhetskopierar en weekendresa medan en annan familjemedlem bläddrar bland äldre album på samma NAS. Stora filer kopieras fortfarande i en respektabel hastighet, men miniatyrerna visas ojämnt och vissa förfrågningar pausar. Den viktiga frågan är om väntan på lagringen ligger bakom just dessa åtgärder, inte om enheten kan uppnå en hög sekventiell överföringshastighet.

Snabba överföringar kan förekomma samtidigt som långsamma små läsningar

Genomströmning beskriver hur många byte som flyttas över tid, medan latens beskriver hur länge en åtgärd väntar innan den slutförs. En disk kan effektivt leverera en stor sekventiell dataström och samtidigt hantera spridda små läsningar mindre snabbt. Surfning i Immich och programmets tillstånd liknar inte alltid en enda kontinuerlig filkopiering, så dessa två observationer kan förekomma samtidigt.

Analys av värdprestanda granskar enhetens väntetid och köbeteende tillsammans med genomströmningen, inte bara en enskild procentandel för utnyttjande. Mätvärden som förfrågningslatens, ködjup, CPU-väntan och applikationstider är användbara tillsammans. Tolkningen beror på lagringsstacken, särskilt där virtualisering, cachelagring eller flera enheter ligger under den rapporterade volymen.

Som ett förenklat exempel tar tjugo beroende åtgärder på 5 millisekunder vardera 100 millisekunder innan annat arbete räknas med. Vid 0,5 millisekunder vardera tar de 10 millisekunder. I verkligheten kan förfrågningar köras parallellt eller använda cachelagring, så detta förklarar ackumulerad väntan och är inte en uppmätt prognos för Immichs svarstid.

Olika dataroller når lagringen på olika sätt

En ursprunglig uppladdning lägger till mediebyte; bakgrundsförberedelser läser indata och skriver härledda filer; surfning hämtar visningsresurser; databasen hanterar applikationsposter och frågor. Samma fysiska pool kan betjäna alla dessa, men deras förfrågningsstorlekar och åtkomstmönster skiljer sig åt. En förändring av lagringen kan därför hjälpa ett steg betydligt mer än ett annat.

En egen Immich-installation placerade PostgreSQL på en SSD och behöll medier och miniatyrer på hårddiskar. Den dokumenterade blandade layouten visar att lagringsroller kan separeras; den bevisar inte att arrangemanget är optimalt eller kvantifierar SSD-hastighetsökningen. Använd sådana exempel för att identifiera vilken roll en observation gäller innan du generaliserar utifrån hårdvarulistan.

För familjesäkerhetskopiering bör du skilja mellan godkända original, färdigberedda förhandsvisningar och sökbara poster. Snabbare skrivningar av original tar inte bort en flaskhals i inferensen, och en snabb databas garanterar inte att en kall bildläsning går snabbt. Den relevanta slutpunkten är den hushållsåtgärd som tidsmäts, inklusive alla steg som krävs för den.

Importer gör delad lagring till en kö

Under en import kan bakgrundsskrivningar och interaktiva läsningar hamna i samma enhetskö. Fler samtidiga jobb kan öka mängden väntande arbete även när den samlade genomströmningen ökar. Den synliga kostnaden märks ofta i enstaka långa förfrågningar, vilket ett genomsnitt kan dölja medan de flesta tidslinjeminiatyrer fortsätter att laddas normalt.

Begäran om separat miniatyrlagring kom uttryckligen från en önskan att använda snabb lagring för genererade bläddringsresurser och bulklagring för original. Det är belägg för olika åtkomstprioriteringar, inte ett universellt påstående om att varje installation behöver separata enheter. Den faktiska nyttan beror på var de aktuella förfrågningarna väntar och på om den föreslagna lagringsnivån förändrar den väntan.

Den här mekanismen slutar förklara långsamheten när enhetens latens förblir stabil men klienten stannar under avkodning, nätverket försöker överföra data på nytt eller inferensen förblir överbelastad. Att då flytta data enbart för att CPU-användningen är låg kan missa orsaken. Delad lagring är en möjlig beroendefaktor, inte ett automatiskt svar på varje paus under importer.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Korrelera diskväntan med en familjeåtgärd

Välj en upprepningsbar familjeåtgärd, till exempel att öppna samma album eller ladda upp ett fastställt testurval. Registrera dess varaktighet på en lugn värd och under en representativ import, tillsammans med enhetens latens, köbeteende, databastider och fel. Behåll konto, nätverksväg, medieinställningar och klient oförändrade så att jämförelsen får en tydlig innebörd.

Samma skillnad mellan kritiska sökvägar syns i analys av lagring i delade hemservrar: bakgrundslagring innebär inte att varje synlig åtgärd väntar på en diskskrivning. Denna princip mellan applikationer hjälper till att rama in observationen, men tider från Home Assistant är inte Immich-riktmärken. Fotoflödet måste visa sin egen koppling mellan lagringsväntan och en fördröjning som användaren kan se.

Se lagring som en stödd förklaring när längre väntetider konsekvent sammanfaller med det fördröjda steget och ett annat kontrollerat villkor förändrar båda. Om bara den första kalla läsningen är långsam ska du registrera det separat från ihållande konkurrens om resurser. Stanna vid det identifierade beroendet; denna mekanismanalys kräver inte destruktiva stresstester på produktionsbiblioteket med foton.