Stel niet één geheugenlimiet voor Immich in op basis van een universeel aantal GB. Een RAM-doelwaarde op hostniveau en een limiet per container lossen verschillende problemen op: de host moet de volledige stack ondersteunen, terwijl een containerlimiet de host moet beschermen zonder een legitieme Immich-workload te beëindigen.
Door een verwerkte bibliotheek bladeren kan licht lijken, terwijl een koude start van machine learning, een grote import, het genereren van miniaturen, gezichtsherkenning of videobewerking veel meer geheugen verbruikt. Meet de zwaarste workload die je daadwerkelijk nodig hebt, houd ruimte over voor PostgreSQL en het besturingssysteem en beschouw herhaalde OOM-beëindigingen als een mislukte limiet, niet als normale begrenzing.
Meet de geheugendruk voordat je de limiet kiest
Leg het geheugengebruik vast in drie situaties: rustig bladeren, een representatieve dagelijkse upload en de zwaarste geplande achtergrondworkload. Registreer het gebruik van de container, het beschikbare geheugen van de host, swapactiviteit, OOM-gebeurtenissen en of taken voortgang blijven maken. Eén piekwaarde uit docker stats is niet voldoende, omdat Linux-geheugenboekhouding verschillende soorten geheugen omvat, met uiteenlopend gedrag bij het vrijmaken.
Een nuttige Docker cgroup-geheugenanalyse maakt onderscheid tussen anoniem geheugen, bestandsondersteunde cache en slab, in plaats van het ruwe totaal als overal even gevaarlijk te behandelen. Een stabiele bestandscache met voldoende ruimte op de host verschilt van gestaag toenemend anoniem geheugen, swapdruk of een cgroup-OOM-teller die tijdens dezelfde Immich-taak oploopt.
Je bent klaar voor deze fase wanneer je een herhaalbaar maximum kunt vaststellen en kunt uitleggen of dit voornamelijk vrijmaakbare cache of actief werkgeheugen betreft. Als het gebruik tijdens een onveranderde workload blijft stijgen, een container herhaaldelijk door OOM wordt beëindigd of de host zwaar begint te swappen, stop dan met dimensioneren op basis van die run en onderzoek eerst de abnormale groei.
Stem de limiet af op de zwaarste geldige Immich-workload
Kies de workload die na het instellen van de limiet ondersteund moet blijven. Voor het ene huishouden kan dat betekenen dat vier telefoons tegelijk uploaden terwijl Smart Search en gezichtstaken hun achterstand inhalen; voor een ander kan het een grote eerste import zijn, gevolgd door normaal bladeren. Houd de dataset, modelinstellingen, concurrency-instellingen en andere containers tijdens het meten gelijk, zodat de limiet een duidelijk omschreven servicebelofte weerspiegelt.
Stel de harde limiet in boven de gemeten piek van niet-vrijmaakbaar geheugen, met voldoende meetbare marge voor korte pieken, en houd tegelijk hostgeheugen vrij voor PostgreSQL, de bestandssysteemcache, de containerruntime en niet-gerelateerde services. De bijbehorende ZimaSpace-checklist voor waarschuwingssignalen voor lokale AI-bronnen is nuttig, omdat hitte, swappen en plotselinge herstarts stress op hostniveau zichtbaar maken die een grafiek van alleen Immich kan missen. Interpreteer “de container raakte de limiet eenmaal” niet als bewijs dat er meer RAM nodig is. De belangrijke grens is of dezelfde geldige workload sterk vertraagt, taken verliest, voortdurend swapt of door OOM wordt beëindigd. Omgekeerd is een limiet te ruim als Immich de database of host kan uithongeren voordat de eigen cgroup de grens bereikt.
Verminder de workload voordat je de limiet verhoogt bij abnormale groei
Als de voorgestelde limiet alleen tijdens één soort achtergrondwerk faalt, verlaag dan de concurrency van die taak of isoleer die fase voordat je de bovengrens verhoogt. Machine learning, het genereren van miniaturen, videobewerking en databasewerk kunnen verschillende geheugenprofielen hebben. Een kleinere actieve batch kan langzamer worden voltooid, terwijl de huishoudelijke interface responsief blijft en de host kan herstellen.
Versieafhankelijke fouten zijn ook van belang. Een geheugenrapport over Immich v3.0.3 beschreef een machine-learningworker die bleef groeien totdat een cgroup-limiet een OOM veroorzaakte na een misvormde, aan locale gerelateerde toestand. Dat geval bepaalt niet het normale RAM-gebruik van Immich; het laat zien waarom onverklaarde groei eerst als een software- of configuratieprobleem moet worden behandeld voordat je het hostbudget permanent verhoogt.
Herhaal dezelfde workload nadat je één variabele voor concurrency, model of versie hebt gewijzigd. Behoud de wijziging alleen als zowel het geheugensignaal als de oorspronkelijke taak in de verwachte richting verbeteren. Als het geheugen blijft stijgen zonder een stabiel plateau te bereiken, bewaar dan logboeken en versiedetails en escaleer het probleem in plaats van de harde limiet steeds verder te verhogen.
Valideer de limiet na een koude herstart en een drukke cyclus
Herstart de host zodat caches en modelresidentie vanuit een bekende koude toestand beginnen. Voer de normale controles voor aanmelden en bladeren uit en daarna de representatieve upload en achtergrondworkload. Registreer de piek van anoniem geheugen, cache, swap, OOM-tellers, database-respons, de tijd om de wachtrij leeg te maken en of een andere belangrijke container responsief blijft.
Een limiet is geslaagd als deze zowel een koude start als de drukste normale cyclus doorstaat zonder OOM-beëindigingen, aanhoudend swapgetrans, herhaalde containerherstarts of een wachtrij die niet meer leegloopt. Er moet ook voldoende ruimte op de host overblijven voor hersteltaken, zoals een databasedump of een beheerdersaanmelding wanneer Immich bezig is.
Als alleen een kunstmatige stresstest faalt terwijl elke vastgestelde huishoudelijke workload slaagt, documenteer dan de geaccepteerde grens in plaats van RAM aan te schaffen voor een scenario dat je niet nodig hebt.
Als een echte workload niet kan slagen zonder de host uit te putten, verlaag dan de concurrency, isoleer machine learning, voeg geheugen toe of verplaats concurrerende services. Herhaal daarna dezelfde validatie voordat je de nieuwe limiet veilig verklaart.
Ondersteuning & Tips
Meer om te lezen

Hoe optimaliseer je Immich-databaseverbindingen voor gelijktijdige containers?
Verhoog max_connections niet als eerste. Meet de Immich-sessies, tel de vraag van elke container bij elkaar op, behoud ruimte voor beheerders en stem alleen...

Dubbele taken of imports in Immich voorkomen
Scheid herhaalde taken van dubbele assets. Gebruik één canoniek ingestiepad, beheer retries en padwijzigingen en test vervolgens opnieuw invoeren op een kleine groep.

Immich herstellen nadat het databasevolume vol raakt
Verwijder nooit PostgreSQL-WAL om ruimte vrij te maken. Stop schrijfbewerkingen van Immich, behoud de databasestatus, voeg veilig extra opslagcapaciteit toe, herstel PostgreSQL en voorkom...

