Waarom pieken de achtergrondtaken van Immich na een wijziging in een bibliotheek?

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.

Werkzaamheden op de achtergrond van Immich kunnen na een wijziging in een bibliotheek pieken, omdat één gebeurtenis in het bestandssysteem of de bibliotheek kan uitwaaieren naar scan-, metadata-, afgeleide- en indexeringstaken.

Het belangrijke onderscheid is dat tussen een begrensde golf van verwachte herverwerking en werk dat assets herhaaldelijk opnieuw verwerkt zonder een overeenkomstige wijziging. Het verplaatsen van een map, het opnieuw scannen van een externe bibliotheek, nieuw ontdekte bestanden of versieafhankelijk gedrag kunnen allemaal vergelijkbare CPU- en wachtrijgrafieken opleveren. Daarom moet de bibliotheekgebeurtenis worden gekoppeld aan de exacte taken die deze heeft aangemaakt.

Een bibliothe scan is een ontdekkingsfase, niet de volledige werklast

Een scan brengt eerst in kaart wat Immich op schijf kan zien en wat het al van de bibliotheek weet. Wanneer een nieuw of gewijzigd asset wordt ontdekt, kunnen downstream-uitvoerbestanden verouderd of ontbrekend zijn. Daardoor ontstaat er extra werk nadat de scan zelf al lijkt te zijn voltooid.

Een praktijkrapport over overlappende bibliotheeksans beschrijft dat een scanwachtrij leeg was, terwijl de wachtrijen voor miniaturen, gezichtsherkenning en andere taken nog zwaar gevuld waren. Het nuttige mechanisme is uitwaaiering: een korte ontdekkingsfase kan een veel langere verwerkingstail veroorzaken.

Lees de wachtrijen in afhankelijkheidsvolgorde. Als de bibliotheekwachtrij tot nul daalt terwijl wachtrijen voor afgeleid werk doorgaan, kan de server simpelweg taken verwerken die door de voltooide scan zijn geproduceerd. De hele periode een herhaalde scan noemen verdoezelt welke fase daadwerkelijk bronnen gebruikt.

Padwijzigingen kunnen eruitzien als werk voor nieuwe assets

Externe bibliotheken zijn bijzonder gevoelig voor wijzigingen in de identiteit en paden van het bestandssysteem. Wanneer bestanden worden gereorganiseerd, moet de toepassing hun nieuwe locaties mogelijk afstemmen op de opgeslagen assetstatus. Afhankelijk van het gedrag van de versie en het bibliotheektype kan dit meer werk veroorzaken dan het aantal werkelijk nieuwe foto's doet vermoeden.

Een discussie uit 2026 over verplaatste externe bestanden documenteert een geval waarin gereorganiseerde paden als nieuwe assets werden behandeld, wat leidde tot opnieuw gegenereerde miniaturen, ML-analyse en videobewerking. Dat is een rapport over een bekende beperking, geen belofte dat elke mapverplaatsing zich identiek gedraagt.

Dit verklaart waarom het reorganiseren van een bibliotheek veel duurder kan zijn dan het toevoegen van hetzelfde aantal nieuwe foto's. Als de bestandspaden en inhoud echter niet zijn gewijzigd, wijst herhaalde volledige regeneratie op een andere oorzaak. Die moet worden onderzocht in plaats van als normaal achtergrondgedrag te worden geaccepteerd.

Downstream-wachtrijen kunnen groeien terwijl het werk wordt voltooid

Een aantal wachtende taken hoeft niet monotoon af te nemen. Wanneer een taak is voltooid, kan een asset in aanmerking komen voor een andere taak of kunnen er meer taken aan een latere fase worden toegevoegd. Tijdens een grote afstemming kan de server daardoor tegelijkertijd actieve voortgang en een groeiende downstream-wachtrij laten zien.

De discussie over een achterstand bij miniaturen merkt op dat nieuwe miniatuurtaken kunnen verschijnen terwijl andere verwerking wordt voltooid. De discussie illustreert ook een nuttige grens: historische bugs en verkeerd geconfigureerde importpaden kunnen pathologische lussen veroorzaken. Een groeiende wachtrij moet daarom worden geïnterpreteerd in de context van versie en paden.

Gebruik tellers voor voltooid werk en controleer steekproefsgewijs recente uitvoer, in plaats van alleen naar het aantal wachtende taken te kijken. Als er miniaturen verschijnen, het aantal voltooide taken stijgt en de verwerkingssnelheid uiteindelijk hoger wordt dan de instroom, loopt de wachtrij leeg, ook als de piek pas optreedt nadat de oorspronkelijke bibliotheekscan is beëindigd.

Een piek is abnormaal wanneer er geen overeenkomende wijziging is

Verwachte achtergrondbelasting moet te herleiden zijn tot een gedefinieerde gebeurtenis: nieuwe assets, een metadata-update, een gewijzigd pad, een modelwijziging of een expliciete regeneratieactie. De verklaring wordt zwakker wanneer dezelfde oude assets herhaaldelijk worden ingepland zonder wijziging in configuratie of inhoud.

Een recent rapport waarin één scan gevolgen had voor andere bibliotheken werk in meerdere externe bibliotheken opnieuw leek te genereren, laat zien waarom de reikwijdte belangrijk is. Beschouw dergelijke rapporten als versiegebonden bewijs dat je met je eigen logboeken moet vergelijken, niet als standaardgedrag van Immich.

Het mechanisme verklaart ook niet langer een host die nog lang actief blijft nadat de relevante wachtrijen leeg zijn. Controleer in dat geval databaseonderhoud, back-ups, een andere container, activiteit in het bestandssysteem of een vastgelopen proces. Een bibliotheekwijziging mag geen algemene verklaring worden voor andere aanhoudende belasting.

Koppel de wijziging aan een taakoverzicht vóór en na de wijziging

Leg vóór een gecontroleerde bibliotheekwijziging het aantal assets vast, evenals de wachtende en actieve aantallen voor belangrijke taken, CPU-gebruik, opslaglatentie en het tijdstip van de laatst voltooide scan. Voeg een kleine, bekende groep toe of verplaats die, voer dezelfde observatie opnieuw uit en noteer precies welke wachtrijen groeien en hoe snel ze leeglopen.

Gebruik de uitleg van ZimaSpace over het Immich-datapad om elke piek toe te wijzen aan ontdekking, verwerking, database of opslag, in plaats van alle achtergrondactiviteit als één categorie te behandelen.

Accepteer de piek wanneer het gegenereerde werk evenredig is aan de gecontroleerde wijziging, uitvoer verschijnt, fouten beperkt blijven en de wachtrijen terugkeren richting hun uitgangsniveau. Schaal het onderzoek op wanneer ongewijzigde assets herhaaldelijk opnieuw worden gegenereerd, de reikwijdte groter is dan de bewerkte bibliotheek of dezelfde taken zonder voortgang blijven mislukken.

Tech & AI HUB

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.