Immich op een multi-app-thuisserver: hoe gedeelde resources de resultaten veranderen

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.

Immich in a Multi-App Home Server: How Shared Resources Change Results

De resultaten van Immich veranderen op een server met meerdere apps, omdat containers ondanks afzonderlijke procesgrenzen beperkte CPU-, geheugen-, opslag- en netwerkcapaciteit delen.

Een fot zoekopdracht kan ’s middags snel zijn en tijdens de back-up, scan of transcodering van een andere toepassing traag worden. De configuratie van Immich is niet veranderd, maar het beschikbare middelenbudget en de inhoud van de cache wel. Daarom moet een goede verklaring rekening houden met de volledige werklast van de host.

Containers scheiden processen, niet de fysieke capaciteit

Containers bieden naamruimten en instelbare limieten, maar worden uiteindelijk op dezelfde processors uitgevoerd en maken meestal gebruik van dezelfde geheugencontroller, schijven en netwerkinterfaces. Een Immich-service kan binnen zijn eigen limiet blijven en toch moeten wachten op niet-gerelateerd werk bij een gedeeld fysiek apparaat of in de kernelplanner.

Een praktijkverslag over Immich met meerdere containers beschrijft een energiezuinige host waarop tientallen containers draaien met doorgaans bescheiden CPU-gebruik. Dat garandeert geen identieke resultaten elders; het laat zien waarom alleen het aantal services zwak bewijs vormt en waarom werkelijk overlappend werk op hostniveau moet worden geobserveerd.

Breng alle geplande en piekbelastende naastliggende taken in kaart: back-ups, mediascans, downloads, databases en videotranscoderingen. Noteer hun starttijden samen met de latentie van Immich. Correlatie bewijst geen causaliteit, maar herhaalde samenhang identificeert een gecontroleerd pauze- of herschedulingexperiment waarmee de vermoedelijke interferentie kan worden getest.

Geheugenconcurrentie verandert welke gegevens in de cache blijven

Immich profiteert ervan wanneer vaak gebruikte databasepagina’s, miniaturen en modelgegevens in het geheugen blijven. Een naastliggende service die haar werkset uitbreidt, kan deze pagina’s verdringen zonder dat er een out-of-memory-gebeurtenis optreedt. Het volgende verzoek moet dan opnieuw opslag- of modelladingskosten betalen die niet bestonden toen de gegevens nog warm waren.

Kingstons bespreking van servergeheugen legt uit dat voldoende capaciteit de afhankelijkheid van tragere opslag bij geheugenzware toepassingen vermindert. Toegepast hier betekent dit niet dat elke thuisserver enterprisegeheugen nodig heeft; het betekent dat cacheverlies een ogenschijnlijk identiek Immich-verzoek kan veranderen in een andere fysieke werklast.

Vergelijk de activiteit van de paginacache, swap, major faults en opslaglezingen voordat en nadat de naastliggende service start. Als het pauzeren ervan het gedrag van warme verzoeken herstelt zonder Immich te wijzigen, speelt de geheugentoestand waarschijnlijk een rol. Alleen een hoog totaalpercentage RAM-gebruik is onvoldoende, omdat gezonde bestandssysteemcaching bewust anders ongebruikt geheugen benut.

Opslagwachtrijen koppelen niet-gerelateerde services aan elkaar

Een back-up kan grote bestanden streamen terwijl Immich kleine database- en miniatuurbewerkingen uitvoert. Zelfs wanneer de totale bandbreedte onder het geadverteerde maximum van een schijf blijft, kan wachtrijvorming de voltooiingstijd van latentiegevoelige verzoeken verhogen. Op netwerkopslag komt daar nog een planner en netwerkpad bij in dezelfde keten van concurrentie.

Het artikel over het gegevenspad van Immich van ZimaSpace laat zien dat het selecteren van zoekresultaten en het weergeven van media afzonderlijke stappen met verschillende afhankelijkheden zijn. Dat onderscheid helpt bij het herkennen van opslagkoppeling: snelle resultaat-ID’s gevolgd door vertraagde miniaturen wijzen op een later punt in het pad dan een database-selectie die zelf al traag is.

Meet de apparaatlatentie en wachtrijdiepte per koppelpunt terwijl je hetzelfde verzoek reproduceert. Pauzeer alleen de vermoedelijk I/O-zware naastliggende service en herhaal de test nadat de caches tot rust zijn gekomen. Als de verbetering meerdere afwisselende runs overleeft, zijn planning of scheiding van opslag gerechtvaardigd; zo niet, keer dan terug naar hypotheses over CPU, geheugen of netwerk.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Gebruik een isolatietest met pauzeren en herhalen

Kies een vast eindpunt, zoals het laden van hetzelfde tijdlijnvenster of het uitvoeren van een bekende slimme zoekopdracht, en definieer koude of warme omstandigheden. Leg drie runs vast met de volledige mix van services. Pauzeer vervolgens één kandidaat-service zonder Immich opnieuw te starten en herhaal dezelfde clientreeks en observatieperiode.

Een verslag over zware concurrentie van Immich tijdens verwerking na een update beschrijft een andere fotoservice die geen uploads meer kon uitvoeren terwijl de host druk bezig was. Het betreft één configuratie en geen universele limiet, maar het toont aan dat een gezonde achtergrondwachtrij toch genoeg gedeelde capaciteit kan verbruiken om een andere interactieve service te hinderen.

Accepteer interferentie pas wanneer het pauzeren een herhaalbare verandering in latentie oplevert en de relevante resource-wachttijd tegelijkertijd afneemt. Test vervolgens een gerichte maatregel: verlaag de gelijktijdigheid, stel een planningsvenster in, gebruik een CPU-quota of geheugenreservering, of scheid de opslag. Bewaar de instellingen voor terugdraaien, omdat het isoleren van één naastliggende service een tweede limiet aan het licht kan brengen.