Vilken minnesgräns bör du ställa in för Immich?

Sätt inte en enda minnesgräns för Immich utifrån ett universellt antal GB. Ett RAM-mål på värdnivå och en gräns per container löser olika problem: värden måste klara hela stacken, medan en containergräns ska skydda värden utan att stoppa en legitim Immich-arbetsbelastning.

Att bläddra i ett bearbetat bibliotek kan verka lätt, medan en kall start av maskininlärning, en stor import, skapande av miniatyrbilder, ansiktsanalys eller videobearbetning förbrukar betydligt mer minne. Mät den tyngsta arbetsbelastning du faktiskt behöver, lämna marginal för PostgreSQL och operativsystemet och betrakta upprepade OOM-avslutningar som ett misslyckat gränsvärde, inte som normal strypning.

Mät minnesbelastningen innan du väljer gränsen

Registrera minnet i tre lägen: lugn bläddring, en representativ daglig uppladdning och den tyngsta planerade bakgrundsbelastningen. Fånga containeranvändning, tillgängligt minne på värden, swap-aktivitet, OOM-händelser och om jobben fortsätter att göra framsteg. En enda topp från docker stats räcker inte, eftersom Linux minnesredovisning omfattar flera minnestyper med olika möjligheter till återvinning.

En användbar uppdelning av Docker cgroups minne skiljer mellan anonymt minne, filbaserad cache och slab i stället för att behandla totalsumman som lika farlig. Stabil filcache med god marginal på värden skiljer sig från stadigt ökande anonymt minne, swaptryck eller en OOM-räknare för cgroup som ökar under samma Immich-jobb.

Gå vidare från detta steg när du kan identifiera en upprepningsbar högsta nivå och förklara om den främst består av minne som kan återvinnas eller aktivt arbetsminne. Om användningen fortsätter att öka under en oförändrad arbetsbelastning, en container upprepade gånger avslutas på grund av OOM eller värden börjar använda mycket swap, ska du sluta dimensionera utifrån den körningen och först felsöka den onormala ökningen.

Dimensionera gränsen efter den tyngsta giltiga Immich-arbetsbelastningen

Välj den arbetsbelastning som måste fortsätta fungera efter att gränsen har tillämpats. För ett hushåll kan det innebära att fyra telefoner laddar upp samtidigt som Smart Search- och ansiktsjobben arbetar ikapp; för ett annat kan det vara en stor första import följd av normal bläddring. Håll datamängd, modeller, inställningar för samtidighet och andra containrar konstanta under mätningen, så att gränsen återspeglar ett definierat tjänstelöfte.

Placera den hårda gränsen över den uppmätta toppen av icke-återvinningsbart minne, med tillräcklig mätbar marginal för korta toppar, samtidigt som du reserverar värdminne för PostgreSQL, filsystemcache, containermotorn och orelaterade tjänster. Den relaterade checklistan från ZimaSpace om varningstecken för resursbrist vid lokal AI är användbar, eftersom värme, swapping och plötsliga omstarter visar belastning på värdnivå som en graf enbart för Immich kan missa. Tolka inte ”containern nådde gränsen en gång” som ett bevis på att mer RAM behövs. Den viktiga felgränsen är om samma giltiga arbetsbelastning blir kraftigt långsammare, förlorar jobb, swappar kontinuerligt eller avslutas på grund av OOM. Omvänt är en gräns för generös om Immich kan svälta ut databasen eller värden innan den egna cgroupen blir gränsen.

Minska arbetsbelastningen innan du höjer gränsen vid onormal tillväxt

Om den föreslagna gränsen bara överskrids under en viss typ av bakgrundsarbete, minska jobbets samtidighet eller isolera steget innan du höjer taket. Maskininlärning, skapande av miniatyrbilder, videobearbetning och databasarbeten kan ha olika minnesprofiler. En mindre aktiv batch kan slutföras långsammare, men samtidigt hålla hushållets gränssnitt responsivt och värden återställningsbar.

Versionsspecifika fel spelar också roll. En minnesrapport för Immich v3.0.3 beskrev en maskininlärningsarbetare som växte tills en cgroup-gräns utlöste OOM efter ett felaktigt tillstånd relaterat till lokalisering. Det fallet definierar inte normal RAM-användning i Immich; det visar varför oförklarad tillväxt bör behandlas som en programvaru- eller konfigurationsfråga innan värdens minnesbudget höjs permanent.

Efter att du ändrat en variabel för samtidighet, modell eller version ska du köra samma arbetsbelastning igen. Behåll ändringen bara om både minnesprofilen och det ursprungliga jobbet förbättras i förväntad riktning. Om minnet fortfarande ökar utan att närma sig en stabil platå, spara loggar och versionsuppgifter och eskalera problemet i stället för att göra den hårda gränsen till ett allt större tal.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Validera gränsen efter en kall omstart och en belastad cykel

Starta om värden så att cache och modellnärvaro börjar från ett känt kallt tillstånd. Kör de normala kontrollerna för inloggning och bläddring, följt av den representativa uppladdningen och bakgrundsarbetsbelastningen. Registrera högsta nivå för anonymt minne, cache, swap, OOM-räknare, databasens svarstid, hur lång tid det tar att tömma kön och om en annan viktig container förblir responsiv.

En godkänd gräns klarar både kallstart och den mest intensiva normala cykeln utan OOM-avslutningar, ihållande swaptröskning, upprepade omstarter av containrar eller en kö som slutar att tömmas. Den ska också lämna tillräckligt med marginal på värden för återställningsuppgifter som en databaskopia eller administrativ inloggning när Immich är upptaget.

Om bara ett artificiellt stresstest misslyckas medan alla definierade hushållsarbetsbelastningar klarar sig, dokumentera den accepterade gränsen i stället för att köpa RAM för ett scenario du inte behöver.

Om en verklig arbetsbelastning inte klarar sig utan att värden töms, ska du minska samtidigheten, isolera maskininlärningen, lägga till minne eller flytta konkurrerande tjänster. Upprepa sedan samma validering innan du förklarar den nya gränsen säker.