Come verificare se Immich è limitato dalla CPU, dalla memoria, dalla rete o dallo storage

Testa Immich con un’unica operazione ripetibile, correla la latenza con le attese delle risorse e conferma il collo di bottiglia sospettato tramite un intervento controllato.

Un’istantanea della dashboard non distingue l’attività utile dalla contesa dannosa. Misura un endpoint, come l’accettazione di un caricamento, la visualizzazione di una miniatura o la risposta della ricerca intelligente, in condizioni fisse per media e client, quindi modifica soltanto la risorsa sospettata di limitare le prestazioni.

Definisci un endpoint e una baseline riproducibile

Inizia definendo l’endpoint in termini osservabili. “Immich è lento” non è verificabile, mentre “le stesse venti miniature della timeline impiegano quattro secondi per apparire dopo un riavvio” lo è. Mantieni invariati client, percorso di rete, account, raccolta di foto e condizione iniziale, così che le esecuzioni successive differiscano soltanto per una variabile intenzionale.

Il modello del percorso dei dati di Immich mostra che caricamento, elaborazione, selezione dal database e distribuzione dei contenuti multimediali attraversano dipendenze diverse. Un test mirato alla selezione dei risultati di ricerca dovrebbe cronometrare separatamente l’elenco dei risultati e il rendering delle immagini; altrimenti una query rapida seguita da letture lente dei file viene riportata come un unico ritardo indistinto.

Esegui la baseline almeno tre volte e conserva sia la mediana sia il percentile utile più lento. Registra la profondità delle code, l’utilizzo della CPU per container, la pressione sulla memoria, l’attività di swap, il throughput di rete e le ritrasmissioni, la latenza del disco e la profondità della coda I/O. Un’ipotesi di collo di bottiglia deve correlare il segnale della risorsa con il ritardo dell’endpoint.

Separa la saturazione della CPU dalla pressione sulla memoria

Un’esecuzione limitata dalla CPU mantiene il lavoro eseguibile in attesa del tempo di elaborazione, quindi la latenza dell’endpoint dovrebbe seguire una saturazione prolungata dei core o il throttling. Un’esecuzione limitata dalla memoria può invece mostrare recupero di memoria, swap, terminazioni dei container o caricamenti ripetuti dei modelli. Entrambe le condizioni possono far apparire occupati i grafici della CPU, ma gli interventi producono risposte diverse.

Una recente guida indipendente alle risorse di Immich suddivide l’utilizzo tra server, PostgreSQL, Redis e componenti di machine learning, invece di considerare la RAM totale come un unico requisito. Questa prospettiva a livello di servizio è importante perché la memoria libera dell’host può coesistere con un limite insufficiente del container, mentre una cache dei file di grandi dimensioni non indica automaticamente una situazione critica.

Verifica la pressione sulla CPU riducendo la concorrenza dei worker in background o assegnando più CPU, mantenendo costante la memoria. Verifica la pressione sulla memoria eliminando l’attività di swap o aumentando un limite di memoria vincolato, senza modificare il numero di worker. Se l’endpoint non migliora in modo coerente, escludi quella risorsa come limite principale per questo test.

Distingui il ritardo di rete da quello dello storage

I limiti di rete e di storage spesso si manifestano insieme perché i contenuti multimediali remoti attraversano entrambi. Un collegamento saturo limita i byte trasferiti al secondo, mentre la contesa dello storage aumenta il tempo di completamento delle letture o delle scritture anche su un collegamento inattivo. Testare da un solo client remoto può quindi attribuire erroneamente la distribuzione lenta dei file al livello sbagliato.

L’analisi degli SSD di Kingston sottolinea l’importanza del lavoro in background, del comportamento del firmware, del caching e dei comandi dell’host, che influenzano la risposta dello storage oltre alla velocità sequenziale dichiarata. In Immich, le numerose operazioni su piccole miniature e sul database rendono la latenza e il comportamento delle code più informativi rispetto al risultato di un singolo test di larghezza di banda su file di grandi dimensioni.

Ripeti l’endpoint da un client locale cablato, quindi dal normale percorso remoto, senza modificare il dataset del server. Leggi separatamente un insieme rappresentativo di file sull’host e osserva la latenza del dispositivo. Un miglioramento visibile solo dal client locale indica il percorso di rete; le attese persistenti sul lato host indicano lo storage o il relativo punto di montaggio.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Usa una matrice degli interventi per accettare o respingere ogni causa

Scrivi quattro righe prima di iniziare i test: CPU, memoria, rete e storage. Per ogni riga indica un sintomo atteso, un intervento mirato e una condizione di esclusione. In questo modo eviti che la diagnosi cambi dopo la comparsa dei risultati e rendi utile anche un esito negativo, invece di usarlo come motivo per acquistare diversi aggiornamenti hardware in una volta sola.

Un resoconto sul campo di Immich, con miniature ritardate nonostante un’ampia larghezza di banda Internet, dimostra perché le sole specifiche non siano sufficienti. L’evidenza rilevante è che una modifica mirata sposti l’endpoint misurato mentre la coorte di file multimediali, la condizione della cache, i job, il client e la versione dell’applicazione rimangono invariati.

Accetta la CPU soltanto se ridurre il carico del processore migliora la latenza; la memoria soltanto se ridurre il recupero migliora la latenza; la rete soltanto se migliorare il percorso produce un effetto; e lo storage soltanto se diminuisce l’attesa del dispositivo o del punto di montaggio. Se due interventi sono efficaci, ripetili in entrambi gli ordini, perché il secondo collo di bottiglia potrebbe diventare visibile solo dopo la rimozione del primo.