Quali dipendenze determinano più spesso il reale limite delle prestazioni di Immich?

Le prestazioni di Immich sono generalmente limitate dalla dipendenza attiva più lenta in uno specifico flusso di lavoro, non da una singola specifica hardware permanente.

Caricamenti, ricerca intelligente, navigazione nella timeline e riproduzione video attraversano combinazioni diverse di client, rete, server, database, worker e spazio di archiviazione. Il limite effettivo cambia quando cambiano l’endpoint o la sovrapposizione delle attività in background; perciò, una risposta utile sulla capacità deve partire da un percorso, non da un elenco di componenti.

Il limite prestazionale appartiene a un endpoint

Un limite prestazionale è la massima velocità utile o la latenza minima raggiungibile per una determinata operazione in condizioni specificate. Non coincide con la percentuale massima di utilizzo della CPU. L’accettazione dei caricamenti, la selezione dei risultati di ricerca, la visualizzazione delle miniature e la riproduzione dei video hanno punti di completamento diversi e quindi catene di dipendenze differenti.

L’articolo di ZimaSpace sul percorso dei dati di Immich distingue l’accettazione dei caricamenti, la disponibilità per l’elaborazione, la selezione dei risultati di ricerca e la distribuzione dei contenuti multimediali. Questa distinzione spiega perché migliorare un worker di machine learning può accelerare l’indicizzazione senza modificare la distribuzione delle miniature e perché un accesso di rete più veloce non può risolvere una query lenta sul database.

Per ogni problema o benchmark, annota l’evento iniziale, l’evento finale, il client, il gruppo di contenuti multimediali, lo stato della cache e il carico di lavoro in background. Solo dopo traccia le fasi necessarie. Il limite è determinato dalla fase il cui tempo di servizio o la cui coda impedisce all’endpoint di migliorare quando il lavoro a monte arriva più rapidamente.

Lo stato del database e delle code limita spesso il coordinamento

Il database seleziona gli elementi e conserva le relazioni dell’applicazione, mentre lo stato delle code coordina il lavoro in background. I relativi ritardi possono limitare le ricerche, le importazioni o la disponibilità, anche quando i worker di elaborazione hanno cicli inutilizzati. Al contrario, una coda profonda può indicare che il lavoro in ingresso supera la capacità di elaborazione dei worker, non che il servizio di coda sia lento.

Un’analisi architetturale approfondita descrive PostgreSQL come il sistema che conserva utenti, elementi, album e incorporamenti vettoriali, mentre Redis gestisce le code di processi asincroni. La fonte è una spiegazione indipendente della distribuzione e qui è utile per la separazione delle dipendenze, non per alcun valore di risorsa fisso.

Osserva insieme il tempo di risposta del database, le attese sulle connessioni, la profondità della coda e i processi completati al minuto. Se la profondità della coda aumenta mentre la produttività dei worker rimane invariata e i tempi del database restano stabili, i worker sono probabilmente il limite. Se ogni fase si interrompe in corrispondenza delle attese del database, aumentare la concorrenza dei worker può peggiorare il limite.

Spazio di archiviazione, memoria e potenza di calcolo si scambiano il collo di bottiglia

La memoria può mantenere le pagine del database, le miniature e i modelli vicini ai processori. Quando il working set non entra più nella memoria, la latenza dello spazio di archiviazione entra nelle richieste che prima avevano la velocità della memoria. Durante le nuove importazioni, invece, le attività intensive per la generazione di miniature, l’elaborazione video e il machine learning possono diventare dominanti. La dipendenza limitante cambia in base allo stato e al carico di lavoro.

Un’analisi del self-hosting di Immich distingue le esigenze moderate dell’applicazione e del database dalla maggiore richiesta di memoria del machine learning e osserva l’effetto del caricamento dei modelli. I valori specifici variano in base alla versione e al modello, ma la lezione sulle dipendenze rimane valida: la RAM complessiva non rivela quale servizio perda il proprio working set.

Confronta le fasi a freddo, a caldo e sostenute. Un grande miglioramento dal freddo al caldo indica il caricamento di modelli o cache; un’elevata latenza del dispositivo durante query ampie indica mancate corrispondenze nel working set; una potenza di calcolo saturata con I/O stabile indica un limite nell’elaborazione. Dopo aver modificato un limite, ripeti l’intero percorso perché ora potrebbe dominare la fase successiva.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Costruisci una mappa endpoint-dipendenze

Crea righe per l’accettazione dei caricamenti, la risposta dei risultati di ricerca, l’ultima miniatura visibile nella timeline e l’avvio del video. Aggiungi colonne per la preparazione del client, il trasferimento di rete, la gestione dell’applicazione, le attività del database o della coda, l’elaborazione dei worker, l’accesso allo spazio di archiviazione e la decodifica del client. Indica le fasi non utilizzate invece di assegnare ogni componente a ogni endpoint.

Un report della community sul trasferimento della generazione delle miniature per una libreria familiare di due terabyte illustra la necessità pratica di distinguere la capacità di elaborazione da quella dello spazio di archiviazione NAS. Non dimostra che l’esternalizzazione sia sempre necessaria; identifica un percorso specifico dei worker che può dominare una grande importazione.

Misura un’esecuzione rappresentativa e assegna una priorità solo alle attese osservate. Proponi un intervento per la fase principale e una condizione di rifiuto. Se l’endpoint migliora, aggiorna la mappa perché il limite si è spostato; se non migliora, scarta l’ipotesi. In questo modo ottieni una catena di prove invece di una lista della spesa.