Quale limite di memoria dovresti impostare per Immich?

Non impostare un unico limite di memoria per Immich basandoti su un numero universale di GB. Un obiettivo di RAM a livello di host e un limite per container risolvono problemi diversi: l’host deve supportare l’intero stack, mentre il limite del container dovrebbe proteggere l’host senza interrompere un carico di lavoro Immich legittimo.

La consultazione di una libreria elaborata può sembrare leggera, mentre un avvio a freddo del machine learning, una grande importazione, la generazione di miniature, l’analisi dei volti o l’elaborazione video possono consumare molta più memoria. Misura il carico di lavoro più pesante di cui hai effettivamente bisogno, lascia margine per PostgreSQL e per il sistema operativo e considera gli arresti ripetuti per OOM come un limite fallito, non come un normale throttling.

Misura la pressione sulla memoria prima di scegliere il limite

Registra la memoria in tre stati: consultazione tranquilla, un caricamento quotidiano rappresentativo e il carico di lavoro in background più pesante previsto. Raccogli l’utilizzo del container, la memoria disponibile sull’host, l’attività di swap, gli eventi OOM e verifica se i processi continuano ad avanzare. Un singolo picco rilevato con docker stats non è sufficiente, perché il conteggio della memoria in Linux include diversi tipi di memoria con comportamenti di recupero differenti.

Una scomposizione della memoria cgroup di Docker distingue la memoria anonima, la cache associata ai file e la slab, invece di trattare il totale grezzo come ugualmente pericoloso. Una cache dei file stabile con un margine sano sull’host è diversa da una memoria anonima in costante aumento, dalla pressione sulla swap o da un contatore OOM del cgroup che aumenta durante lo stesso processo Immich.

Supera questa fase quando puoi identificare un limite massimo ripetibile e spiegare se è costituito soprattutto da cache recuperabile o da memoria di lavoro attiva. Se l’utilizzo continua ad aumentare con un carico di lavoro invariato, un container viene terminato ripetutamente per OOM oppure l’host inizia a usare intensamente la swap, interrompi il dimensionamento basato su quella sessione e diagnostica prima la crescita anomala.

Dimensiona il limite in base al carico di lavoro Immich valido più pesante

Scegli il carico di lavoro che deve rimanere supportato dopo l’applicazione del limite. Per una famiglia potrebbe significare quattro telefoni che caricano foto mentre Smart Search e i processi per i volti recuperano il ritardo; per un’altra potrebbe trattarsi di una grande importazione iniziale seguita dalla normale consultazione. Mantieni invariati il dataset, il modello, le impostazioni di concorrenza e gli altri container durante le misurazioni, così il limite rifletterà una promessa di servizio definita.

Imposta il limite rigido al di sopra del picco non recuperabile osservato, con un margine misurabile sufficiente per i brevi picchi, preservando al contempo memoria dell’host per PostgreSQL, la cache del filesystem, il runtime dei container e i servizi indipendenti. La checklist ZimaSpace correlata sui segnali di avvertimento delle risorse per l’IA locale è utile perché calore, swap e riavvii improvvisi rivelano uno stress a livello di host che un grafico limitato a Immich può non mostrare. Non interpretare il fatto che «il container abbia raggiunto il limite una volta» come prova che serva più RAM. Il confine di errore importante è se lo stesso carico di lavoro valido rallenta gravemente, perde processi, usa continuamente la swap o viene terminato per OOM. Al contrario, un limite è troppo permissivo se Immich può privare il database o l’host di risorse prima che il suo cgroup diventi il limite effettivo.

Riduci il carico di lavoro prima di aumentare il limite per una crescita anomala

Se il limite proposto fallisce solo durante una determinata categoria di attività in background, riduci la concorrenza di quel processo o isola la fase prima di aumentare il tetto. Il machine learning, la generazione di miniature, l’elaborazione video e le operazioni sul database possono avere profili di memoria diversi. Un batch attivo più piccolo può completarsi più lentamente, mantenendo però reattiva l’interfaccia domestica e consentendo all’host di recuperare.

Anche i problemi specifici di versione sono importanti. Un report sulla memoria di Immich v3.0.3 descriveva un worker di machine learning che continuava a crescere fino a provocare un OOM al raggiungimento del limite del cgroup, a causa di una condizione anomala legata alla lingua locale. Questo caso non definisce il normale utilizzo della RAM di Immich; dimostra perché una crescita inspiegabile dovrebbe essere trattata prima come un problema software o di configurazione, invece di aumentare permanentemente il budget dell’host.

Dopo aver modificato una sola variabile tra concorrenza, modello o versione, esegui nuovamente lo stesso carico di lavoro. Mantieni la modifica solo se migliorano nella direzione prevista sia il profilo della memoria sia il processo originale. Se la memoria continua ad aumentare senza raggiungere un plateau stabile, conserva i log e i dettagli della versione e procedi con un’escalation invece di trasformare il limite rigido in un numero sempre più grande.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Convalida il limite dopo un riavvio a freddo e un ciclo intenso

Riavvia l’host in modo che le cache e la presenza dei modelli in memoria partano da uno stato noto e privo di dati memorizzati. Esegui i normali controlli di accesso e consultazione, quindi il caricamento rappresentativo e il carico di lavoro in background. Registra il picco della memoria anonima, la cache, la swap, i contatori OOM, la risposta del database, il tempo necessario a svuotare la coda e verifica che un altro container importante rimanga reattivo.

Un limite superato con esito positivo resiste sia all’avvio a freddo sia al ciclo normale più intenso senza terminazioni per OOM, uso prolungato e aggressivo della swap, riavvii ripetuti del container o una coda che smette di svuotarsi. Dovrebbe inoltre lasciare all’host un margine sufficiente per attività di ripristino, come un dump del database o un accesso amministrativo, mentre Immich è occupato.

Se fallisce solo un test di stress artificiale mentre tutti i carichi di lavoro domestici definiti hanno esito positivo, documenta il limite accettato invece di acquistare RAM per uno scenario di cui non hai bisogno.

Se un carico di lavoro reale non può essere completato senza esaurire le risorse dell’host, riduci la concorrenza, isola il machine learning, aggiungi memoria o sposta i servizi concorrenti; quindi ripeti la stessa convalida prima di dichiarare sicuro il nuovo limite.