Hoe je test of Immich wordt beperkt door CPU, geheugen, netwerk of opslag

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How to Test Whether Immich Is CPU-, Memory-, Network-, or Storage-Bound

Test Immich met één herhaalbare handeling, breng de latentie ervan in verband met wachttijden op resources en bevestig de vermoedelijke bottleneck via een gecontroleerde ingreep.

Een dashboardmomentopname kan geen onderscheid maken tussen nuttige activiteit en schadelijke contention. Meet één endpoint—zoals het accepteren van uploads, het weergeven van miniaturen of de respons van slim zoeken—onder vaste media- en clientomstandigheden en wijzig vervolgens alleen de vermoedelijk beperkende resource.

Definieer één endpoint en een reproduceerbare nulmeting

Begin door het endpoint in waarneembare termen te benoemen. “Immich is traag” is niet testbaar, maar “dezelfde twintig tijdlijnminiaturen verschijnen na een herstart in vier seconden” wel. Leg de client, het netwerkpad, het account, de fotocollectie en de startsituatie vast, zodat latere runs slechts op één bedoelde variabele verschillen.

Het datapadmodel van Immich laat zien dat uploaden, verwerken, database-selectie en mediabezorging verschillende afhankelijkheden doorlopen. Een test die op zoekselectie is gericht, moet de resultatenlijst afzonderlijk timen van het renderen van afbeeldingen; anders wordt een snelle query gevolgd door trage bestandslezingen als één ongedifferentieerde vertraging gerapporteerd.

Voer de nulmeting minstens drie keer uit en bewaar zowel de mediaan als het hoogste relevante percentiel. Noteer de wachtrijdiepte, CPU-gebruik per container, geheugendruk, swapactiviteit, netwerkdoorvoer en retransmissies, schijflatentie en I/O-wachtrijdiepte. Een bottleneckclaim moet het resourcesignaal in overeenstemming brengen met de vertraging van het endpoint.

Maak onderscheid tussen CPU-verzadiging en geheugendruk

Bij een CPU-gebonden run blijft uitvoerbaar werk wachten op processortijd, waardoor de endpointlatentie moet correleren met langdurige coreverzadiging of throttling. Bij een geheugen-gebonden run zie je mogelijk juist reclaim, swap, beëindigde containers of het herhaald laden van modellen. Beide kunnen CPU-grafieken druk laten lijken, maar hun ingrepen leveren verschillende reacties op.

Een recente onafhankelijke Immich-resourcegids splitst het gebruik uit over de server-, PostgreSQL-, Redis- en machine-learningcomponenten, in plaats van totale RAM als één vereiste te behandelen. Dat perspectief per service is belangrijk, omdat vrije hostgeheugenruimte kan samengaan met een te lage containerlimiet, terwijl een grote bestandscache niet automatisch op problemen wijst.

Controleer CPU-druk door de gelijktijdigheid van achtergrondwerkers te verlagen of meer CPU toe te wijzen terwijl het geheugen gelijk blijft. Controleer geheugendruk door swapactiviteit te verwijderen of een beperkte geheugenlimiet te verhogen zonder het aantal werkers te wijzigen. Als het endpoint niet consistent verbetert, verwerp die resource dan als de primaire grens voor deze test.

Maak onderscheid tussen netwerkvertraging en opslagvertraging

Netwerk- en opslaglimieten treden vaak samen op, omdat externe media beide doorloopt. Een verzadigde verbinding beperkt het aantal overgedragen bytes per seconde, terwijl opslagcontentie de voltooiingstijd van lees- of schrijfbewerkingen verhoogt, zelfs op een rustige verbinding. Testen vanaf slechts één externe client kan trage bestandsbezorging daarom aan de verkeerde laag toeschrijven.

Kingstons SSD-analyse benadrukt achtergrondwerk, firmwaregedrag, caching en hostcommando’s die de opslagrespons beïnvloeden naast de nominale sequentiële snelheid. Voor Immich zijn latentie en wachtrijgedrag informatiever dan één bandbreedtetest met een groot bestand, omdat veel kleine miniatuur- en databasebewerkingen plaatsvinden.

Herhaal het endpoint vanaf een bekabelde lokale client en daarna via het normale externe pad, zonder de serverdataset te wijzigen. Lees afzonderlijk een representatieve bestandsset op de host en let op de apparaatlatentie. Verbetering alleen bij de lokale client wijst op het netwerkpad; aanhoudende wachttijden aan de hostzijde wijzen op opslag of de koppeling daarvan.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Gebruik een interventiematrix om elke oorzaak te accepteren of te verwerpen

Schrijf vóór het testen vier rijen op: CPU, geheugen, netwerk en opslag. Geef elke rij één verwacht symptoom, één gerichte interventie en één voorwaarde voor verwerping. Zo voorkom je dat de diagnose na het verschijnen van de resultaten verandert en wordt een negatieve bevinding nuttig, in plaats van een reden om meerdere upgrades tegelijk aan te schaffen.

Een openbaar praktijkrapport over Immich met vertraagde miniaturen ondanks een aanzienlijke internetbandbreedte laat zien waarom specificaties alleen niet volstaan. Het relevante bewijs is of een gerichte wijziging het gemeten endpoint verbetert terwijl de mediagroep, cachetoestand, taken, client en applicatieversie gelijk blijven.

Accepteer CPU alleen als verlichting van de processor de latentie verbetert; geheugen alleen als verlichting van reclaim dat doet; netwerk alleen als verlichting van het pad dat doet; en opslag alleen als een lagere wachttijd op apparaat of koppeling dat doet. Als twee interventies helpen, herhaal ze dan in beide volgordes, omdat de tweede bottleneck mogelijk pas zichtbaar wordt nadat de eerste is weggenomen.