Hoe opslaglatentie de back-up van familiefoto’s in Immich verandert

Opslaglatentie vertraagt Immich wanneer vereiste lees- of schrijfbewerkingen moeten wachten, vooral wanneer imports concurreren met databaseactiviteit en het browsen op gedeelde apparaten.

Twee telefoons maken een back-up van een weekendtrip terwijl een ander gezinslid op dezelfde NAS door oudere albums bladert. Grote bestanden worden nog steeds met een respectabele snelheid gekopieerd, maar tegels verschijnen onregelmatig en sommige aanvragen pauzeren. De belangrijke vraag is of wachten op opslag bij die specifieke bewerkingen een rol speelt, niet of de schijf een hoge sequentiële overdrachtsscore kan behalen.

Snelle overdrachten kunnen samengaan met trage kleine leesbewerkingen

Doorvoer beschrijft hoeveel bytes er in een bepaalde tijd worden verplaatst; latentie beschrijft hoe lang een bewerking wacht voordat deze is voltooid. Een schijf kan een grote sequentiële gegevensstroom efficiënt leveren en tegelijkertijd verspreide kleine leesbewerkingen minder snel afhandelen. Browsen in Immich en de applicatiestatus lijken niet altijd op één doorlopende bestandskopie, dus beide observaties kunnen naast elkaar bestaan.

Prestatieanalyse van de host onderzoekt het wachten op apparaten en het gedrag van wachtrijen naast de doorvoer, en niet alleen één percentage voor gebruik. Metingen zoals aanvraaglatentie, wachtrijdiepte, CPU-wachttijd en applicatietiming zijn samen nuttig. De interpretatie ervan hangt af van de opslagstack, vooral wanneer virtualisatie, caching of meerdere apparaten onder het gerapporteerde volume liggen.

Als vereenvoudigd voorbeeld nemen twintig afhankelijke bewerkingen van elk 5 milliseconden 100 milliseconden in beslag voordat ander werk wordt meegerekend. Bij 0,5 milliseconde per bewerking is dat 10 milliseconden. In werkelijkheid kunnen aanvragen gelijktijdig worden uitgevoerd of caches gebruiken, dus dit is een uitleg van opgetelde wachttijd en geen gemeten voorspelling van de reactietijd van Immich.

Verschillende gegevensrollen bereiken opslag op verschillende manieren

Een oorspronkelijk uploadbestand voegt mediabytes toe; verwerking op de achtergrond leest invoer en schrijft afgeleide bestanden; browsen haalt weergave-assets op; de database verwerkt applicatierecords en query's. Dezelfde fysieke pool kan dit allemaal bedienen, maar de aanvraaggroottes en toegangspatronen verschillen. Een wijziging in de opslag kan daarom de ene fase veel meer helpen dan de andere.

Een praktijkvoorbeeld van een Immich-configuratie plaatste PostgreSQL op een SSD en behield media en miniaturen op harde schijven. Die gedocumenteerde gemengde indeling laat zien dat opslagrollen kunnen worden gescheiden; ze bewijst niet dat deze indeling optimaal is en kwantificeert evenmin een SSD-versnelling. Gebruik zulke voorbeelden om vast te stellen op welke rol een observatie betrekking heeft voordat je generaliseert op basis van de hardwarelijst.

Maak bij back-ups van het gezin onderscheid tussen geaccepteerde originelen en volledig voorbereide voorbeelden en doorzoekbare records. Snellere schrijfbewerkingen van originelen nemen een inferentieknelpunt niet weg, en een snelle database garandeert niet dat een koude afbeeldingsleesbewerking snel is. Het relevante eindpunt is de gezinsactie waarvan de tijd wordt gemeten, inclusief alle vereiste fasen.

Imports veranderen gedeelde opslag in een wachtrij

Tijdens een import kunnen achtergrondschrijfbewerkingen en interactieve leesbewerkingen in dezelfde apparaatwachtrij terechtkomen. Meer gelijktijdige taken kunnen de hoeveelheid werk die wacht vergroten, zelfs wanneer de totale doorvoer stijgt. De zichtbare kosten komen vaak tot uiting in incidenteel lange aanvragen, die een gemiddelde kan verbergen terwijl de meeste tijdlijnt tegels normaal blijven laden.

Het verzoek om afzonderlijke miniaturenopslag kwam expliciet voort uit de wens om snelle opslag te gebruiken voor gegenereerde browse-assets en bulkopslag voor originelen. Dat is bewijs van verschillende toegangsprioriteiten, geen universele bewering dat elke installatie afzonderlijke schijven nodig heeft. Het werkelijke voordeel hangt af van waar huidige aanvragen wachten en of de voorgestelde opslaglaag dat wachten verandert.

Dit mechanisme verklaart de vertraging niet langer wanneer de apparaatlatentie stabiel blijft, maar de client hapert tijdens het decoderen, het netwerk overdrachten opnieuw probeert of inferentie verzadigd blijft. Gegevens verplaatsen alleen omdat het CPU-gebruik laag is, kan dan de oorzaak missen. Gedeelde opslag is een mogelijke afhankelijkheid, geen automatisch oordeel over elke pauze tijdens imports.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Koppel schijfwachttijd aan een gezinsactie

Kies één herhaalbare gezinsactie, zoals hetzelfde album openen of een vast voorbeeld uploaden. Leg de duur ervan vast op een rustige host en tijdens een representatieve import, samen met apparaatlatentie, wachtrijgedrag, databasetiming en fouten. Houd account, netwerkroute, media-instellingen en client ongewijzigd, zodat de vergelijking een duidelijke betekenis heeft.

Hetzelfde onderscheid tussen de kritieke route komt naar voren in analyse van opslag voor gedeelde thuisservers: persistentie op de achtergrond betekent niet dat elke zichtbare actie op een schrijfbewerking naar de schijf wacht. Dat toepassingsoverschrijdende principe helpt de observatie te kaderen, maar metingen van Home Assistant zijn geen benchmarks voor Immich. De fotoworkflow moet zelf het verband aantonen tussen wachten op opslag en zichtbare vertraging voor de gebruiker.

Beschouw opslag als een ondersteunde verklaring wanneer langere wachttijden consequent samenvallen met de vertraagde fase en een andere gecontroleerde toestand beide verandert. Als alleen de eerste koude leesbewerking traag is, leg dat dan afzonderlijk vast van aanhoudende concurrentie. Stop bij de vastgestelde afhankelijkheid; voor deze mechanismeanalyse zijn geen destructieve stresstests op de productiefotobibliotheek nodig.