Come capire se Immich è limitato dalla CPU, dalla RAM, dallo spazio di archiviazione o dalla rete

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Tell Whether Immich Is Limited by CPU, RAM, Storage, or Network - Zima Store Online

Individua ciò che limita Immich riproducendo un carico di lavoro fisso di caricamento, esplorazione, ricerca o attività in background e correlando il relativo tasso di completamento con la saturazione della CPU, la pressione sulla memoria, la latenza dello storage e il throughput di rete nello stesso intervallo.

Un'alta percentuale da sola non indica un collo di bottiglia: una CPU al massimo può funzionare normalmente durante l'apprendimento automatico, molta RAM può essere una cache del file system e un caricamento lento può dipendere dal telefono o dal Wi-Fi. Misura dal client attraverso il container fino all'host, registra l'avanzamento della coda, quindi modifica un solo vincolo sospetto e ripeti il test. La risorsa il cui alleggerimento migliora lo stesso carico di lavoro è il limite determinante.

Costruisci un test e una sequenza temporale ripetibili

Scegli il sintomo che devi migliorare: acquisire un lotto fisso di file multimediali, aprire originali non memorizzati nella cache, generare miniature, eseguire Smart Search o transcodificare un video. Registra l'inizio, il primo risultato utilizzabile, il completamento, gli errori e l'avanzamento della coda dei processi. Mescolare le attività produce grafici delle risorse senza portare a una decisione.

Un'indagine di un utente descrive un'implementazione di Immich insolitamente lenta e cerca prove relative a CPU, memoria, disco e rete. Il suo approccio diagnostico tra le risorse è utile, ma il tuo test fisso deve determinare la causa sul tuo server.

Ripeti il test una volta dopo che le cache si sono riscaldate. Se la seconda esecuzione è molto più veloce, indica lo stato della cache invece di definire l'hardware incoerente. Se entrambe le esecuzioni si bloccano nella stessa fase, allinea quel timestamp con le metriche dell'host e del container e con l'attività responsabile.

Identifica i segnali di CPU e memoria

Una limitazione della CPU mostra un'attività eseguibile sostenuta sui core interessati mentre il processo avanza in proporzione; ridurre la concorrenza può migliorare l'interazione, ma allungare il tempo di completamento. Se un thread è al massimo mentre l'utilizzo totale della CPU appare moderato, controlla la vista per processo e per core prima di presumere che ci sia capacità inutilizzata.

Una limitazione della memoria richiede prove di pressione: aumento dello swap, recupero di memoria, page fault maggiori, terminazioni per esaurimento della memoria o riavvii dei container. Un'elevata quantità di memoria utilizzata con cache stabile, nessuno swap e latenza normale non supera il test. Ripeti l'esecuzione con un worker a concorrenza inferiore o con un modello più piccolo e confronta il completamento.

Un caso segnalato di miniature di Immich v2.5.5 ha consumato una quantità estrema di memoria in un'implementazione. Il rapporto sulla memoria riferito a una versione specifica giustifica il controllo del processo che fallisce e della release; non stabilisce un normale requisito di RAM.

Separa la latenza dello storage dal throughput di rete

Per lo storage, osserva la latenza del dispositivo, la profondità della coda, il throughput, lo spazio disponibile nel file system e la disponibilità degli inode mentre viene eseguito esattamente quel processo. Un basso numero di megabyte al secondo può comunque indicare un limite dello storage quando molte operazioni di piccole dimensioni sul database e sulle miniature attendono un disco ad alta latenza.

Per la rete, misura sia sul client sia sul server, quindi confronta i percorsi locali e remoti. Un collegamento saturo, ritrasmissioni, tentativi ripetuti del Wi-Fi o il limite di una VPN che coincidono con il trasferimento indicano un limite di rete. Se il traffico di caricamento termina ma l'elaborazione resta lenta, segui invece la coda lato server.

La panoramica di ZimaSpace sui servizi per hardware meno recente offre un contesto per la pianificazione del sistema; questa diagnosi dovrebbe comunque basarsi sulla latenza osservata e sul tasso di lavoro, non su etichette relative all'età.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Allevia un vincolo e verifica lo stesso carico di lavoro

Modifica una sola variabile sicura: riduci la concorrenza di un processo, aggiungi un test temporaneo con limite di memoria, sposta una copia dei dati attivi su uno storage più veloce oppure esegui il test su una rete locale cablata. Mantieni confrontabili il dataset, le versioni e lo stato della cache. Un miglioramento sia nel completamento sia nella metrica prevista supera il test causale.

Non acquistare hardware sulla base di una media durante l'inattività o di un singolo picco. Vale la pena aggiornare una risorsa quando controlla ripetutamente il carico di lavoro importante, dopo aver escluso errori software, problemi di spazio libero e attività pianificate concorrenti.

Ripristina le modifiche che spostano il problema a un altro livello o allungano le code oltre l'obiettivo del servizio. Se il sistema si blocca senza che alcuna risorsa mostri pressione, segnala il problema includendo la definizione del carico di lavoro, i timestamp, le metriche per container, la latenza del disco, i test di rete, l'avanzamento della coda e i log; questo schema può indicare un lock, una dipendenza o un errore dell'applicazione.