Waarom groeien de opslagruimtes voor miniaturen en machine learning van Immich tijdens grote imports vanaf mobiele apparaten?

Grote imports vergroten doorgaans de Immich-opslag, omdat elk item afgeleide bestanden en databasegegevens oplevert, terwijl gedownloade modellen in een afzonderlijke cache staan.

Een gezin verplaatst jarenlang gemaakte telefoonfoto’s naar een thuis-NAS en ziet daarna de vrije ruimte blijven afnemen, zelfs nadat de uploadteller klaar is. Dat kan wijzen op legitieme achtergrondverwerking in plaats van op een extra kopie van elk origineel. Het nuttige onderscheid ligt tussen bestanden die per item worden gegenereerd, gedeelde modelbestanden en groei die doorgaat zonder overeenkomstige toename van voltooid werk.

Eén upload creëert verschillende soorten gegevens

Het geüploade origineel is slechts één onderdeel van de uiteindelijke bibliotheek. Immich maakt ook kleinere versies voor het bladeren en slaat informatie op die het item koppelt aan de eigenaar, datums, albums en zoekfuncties. Deze uitvoer dient verschillende verzoeken, dus het voltooien van de netwerkoverdracht betekent niet dat elke daaropvolgende schrijfbewerking al klaar is.

Het onderscheid tussen mediabestanden en databasegegevens is hier belangrijk: applicatiemetadata en zoekinsluitingen staan in PostgreSQL en zijn geen extra foto’s met volledige resolutie. De machinelearningservice berekent resultaten die door de applicatie worden gebruikt. Alle extra bytes behandelen als gedupliceerde originelen geeft daarom een verkeerde verklaring voor normale importgroei.

Stel dat een telefoon de overdracht voltooit terwijl de server de geaccepteerde batch nog verwerkt. Originelen kunnen al stabiel op schijf staan, maar voorvertoningen en doorzoekbare records kunnen nog steeds verschijnen. Vergelijk opslagmetingen in dezelfde verwerkingsfase; een zojuist geüploade groep en een volledig verwerkte groep zijn geen gelijkwaardige steekproeven.

Het aantal items verklaart meer dan het aantal gigabytes aan originelen

Voor het plannen van miniaturen verklaren het aantal en het type items vaak meer dan het totale aantal gigabytes aan originelen. Duizend kleine foto’s en enkele lange video’s kunnen ongeveer dezelfde broncapaciteit innemen, maar heel verschillende aantallen afbeeldingsafgeleiden vereisen. Afmetingen van voorvertoningen, compressie-instellingen en beeldinhoud veranderen de gegenereerde bytes bovendien.

Gepubliceerde metingen van miniaturen illustreren die variatie: één eigenaar meldde 6,3 GB voor een bibliotheek van 70 GB, terwijl een ander ongeveer 370 GB meldde voor 2 TB aan foto’s en video’s. Dit zijn afzonderlijke configuraties, geen vergelijkbare gecontroleerde benchmarks. Ze laten zien waarom het overnemen van één percentage uit een forum een ander huishouden verkeerd kan voorstellen.

Als illustratieve berekening: voor 100.000 items met gemiddeld 250 KB aan gemeten afbeeldingsafgeleiden is ongeveer 25 GB in decimale eenheden nodig. Bij 500 KB per item heeft hetzelfde aantal ongeveer 50 GB nodig. Geen van beide cijfers omvat originelen, gecodeerde video, databasegroei of back-ups; het voorbeeld isoleert de relatie per item en beveelt geen universele marge aan.

Modelbestanden en zoekrecords groeien op verschillende manieren

De modelcache bevat herbruikbare modelbestanden, terwijl zoekvectoren individuele items vertegenwoordigen. Met een vaste set gedownloade modellen hoeven niet voor elke foto opnieuw volledige modellen te worden gedownload. Het toevoegen of wijzigen van modellen kan de cache-opslag daarentegen stapsgewijs vergroten, onafhankelijk van het aantal geüploade foto’s.

Een draagbare implementatie uit de praktijk bewaart de bibliotheek, modelcache en PostgreSQL-gegevens in afzonderlijke permanente mappen. Die scheiding maakt elke opslagfunctie zichtbaar zonder aan te nemen dat één gecombineerde Docker-grootte de uitvoer van machine learning vertegenwoordigt. Het is een indelingsvoorbeeld uit een oudere release, geen actuele installatiehandleiding of aanbevolen set containertags.

Maak ook onderscheid tussen schijfgebruik en geladen geheugen. Een model kan op schijf blijven staan terwijl de kopie in het geheugen wordt verwijderd, en bestandssysteemcaching kan het gerapporteerde geheugengebruik verhogen zonder meer permanente bestanden te creëren. Om een sprong te verklaren, bepaal je eerst welke map de eigenaar is en welke instelling is gewijzigd, voordat je conclusies trekt op basis van een containernaam.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Waar normale groei niet langer volstaat als verklaring

Normale groei van afgeleiden heeft een begrensde invoer: een vaste groep originelen die onder vaste instellingen wordt verwerkt. Er zou geen eindeloos groeiende populatie van nieuwe bronitems moeten ontstaan. Als het aantal items blijft toenemen nadat alle geplande imports zijn gestopt, moet de verklaring rekening houden met ontdekkingspaden, herhaalde inname of een andere bron van nieuw werk.

In een bevestigd geval van recursief scannen bevond de Immich-uploadlocatie zich binnen een externe bibliotheek. Gegenereerde miniaturen werden vervolgens als nieuwe afbeeldingen behandeld, waardoor opnieuw afgeleiden van afgeleiden werden gemaakt. Dit is een ander oorzakelijk mechanisme dan een grote mobiele upload en mag niet worden gebruikt als bewijs dat elke grote bibliotheek zich vanzelf onbeperkt vermenigvuldigt.

Ongebruikelijke groei in een schrijfbare containerlaag is een andere categorie. Een rapport uit 2026 beschreef dat daar honderden gigabytes opstapelden; de discussie stelde geen universele oorzaak vast. Verwijder geen databasebestanden, media of interne Docker-gegevens om een grafiek er normaal uit te laten zien. Bepaal eerst welke functie groeit en of voltooid werk dit verklaart.

Meet de import per opslagfunctie

Noteer vóór een representatieve import het aantal en de omvang van de originele items, de omvang van miniaturen en voorvertoningen, de omvang van gecodeerde video, de databasegrootte, de omvang van de modelcache en eventuele groei van tijdelijke bestanden of logboeken. Herhaal dit nadat diezelfde groep alle ingeschakelde verwerkingstaken heeft voltooid. Houd de media-instellingen ongewijzigd, zodat verschillen aan de import kunnen worden toegeschreven en niet aan een gelijktijdige configuratiewijziging.

Opslagadministratie vervangt geen back-upplan voor het gezin. Een bruikbare fotoservice heeft beschermde originelen nodig, evenals de applicatiestatus die vereist is om de bibliotheek te reconstrueren; alleen een map met miniaturen kan de gezinscollectie niet behouden. Houd deze beschermingstaak gescheiden van het meten van opnieuw genereerbare overhead, zodat een experiment om ruimte te besparen niet de enige kopie van een herinnering wordt.

Accepteer het resultaat wanneer de totalen per opslagfunctie de toegevoegde bytes verklaren en er geen onverwachte bronitems blijven verschijnen. Onderzoek een ander mechanisme wanneer de modelinventaris ongewijzigd is maar de groei van de cache of de schrijfbare laag aanhoudt, of wanneer afgeleide bestanden opnieuw worden ontdekt. Deze test beantwoordt waarom de opslag is gegroeid zonder een verklaring om te zetten in een destructieve opruimprocedure.