Quante attività simultanee può gestire Immich prima che la reattività della ricerca diminuisca?
Immich non ha un numero universale di attività sicuro; la ricerca peggiora quando i worker concorrenti saturano la risorsa necessaria anche alle richieste interattive.
Due server possono eseguire lo stesso numero di attività di generazione delle miniature, elaborazione dei metadati e machine learning, producendo tuttavia latenze di ricerca molto diverse. Il limite utile è quindi il carico di lavoro misto massimo che mantiene un obiettivo definito per i tempi di risposta interattivi mentre la coda continua a svuotarsi.
Il numero di attività non descrive il carico di lavoro
Un valore di concorrenza indica solo il numero consentito di worker, non una misura diretta della pressione sulle risorse. La generazione delle miniature, la transcodifica video, l'estrazione dei metadati e l'inferenza di machine learning richiedono quantità diverse di risorse di calcolo e archiviazione. Quattro attività leggere di elaborazione dei metadati possono lasciare l'interfaccia reattiva, mentre due attività video possono impegnare lo stesso host in modo molto più intenso.
Un report della community sull'elevato utilizzo della CPU da parte del machine learning descrive la riduzione delle attività concorrenti dopo una grande importazione, con conseguente diminuzione del carico ma aumento del tempo di completamento. Questa osservazione conferma il compromesso centrale: una concorrenza inferiore protegge la reattività in primo piano consentendo al backlog di svuotarsi più lentamente, non eliminando il lavoro sottostante.
Tratta ogni coda come una classe di carico di lavoro. Registra quali attività sono attive, quale tipo di contenuti elaborano e se è disponibile l'accelerazione. Un totale sicuro ricavato da piccoli file JPEG non può essere applicato alle foto RAW o ai video lunghi, perché è cambiato il lavoro rappresentato da ogni slot.
La ricerca peggiora al primo punto di saturazione condiviso
La ricerca interattiva attraversa diversi livelli condivisi: la richiesta raggiunge l'applicazione, il database seleziona i risultati, le miniature vengono lette e un client le visualizza. I worker in background possono competere su più di un livello. Il primo livello a saturarsi diventa il limite pratico della concorrenza, anche quando ogni container rimane integro.
Una discussione sulle prestazioni di Immich descrive il caricamento ritardato delle miniature su un host con una larghezza di banda nominale adeguata, illustrando perché la sola velocità del collegamento non può identificare il collo di bottiglia. La pianificazione della CPU, le letture del database, la latenza del filesystem e la distribuzione al client restano tutte possibilità finché le misurazioni non mostrano quale attesa aumenta durante la richiesta lenta.
L'utilizzo deve essere valutato insieme alla latenza. Un'elevata attività della CPU con una latenza di ricerca stabile può indicare una saturazione produttiva, mentre un'attività moderata della CPU associata a un aumento dell'attesa del disco può identificare una coda di archiviazione. La pressione sulla memoria è importante quando il recupero o lo swap aggiungono latenza, non semplicemente perché il sistema operativo utilizza la RAM disponibile come cache.
La ricercabilità può rimanere indietro senza query di ricerca lente
Una query veloce può restituire una raccolta ricercabile incompleta quando i nuovi asset non hanno ancora terminato l'indicizzazione. Al contrario, ogni elemento può essere già indicizzato mentre le query sono lente a causa della contesa nell'accesso al database o allo storage. Definire entrambe le condizioni come “degrado della ricerca” nasconde due risultati finali diversi e porta a correggere la concorrenza nel modo sbagliato.
La spiegazione di ZimaSpace sul percorso dei dati di Immich distingue l'accettazione del caricamento, la disponibilità dell'anteprima e il recupero semantico come risultati finali distinti. Questa distinzione è essenziale durante i test di carico: il momento in cui arriva un file non può sostituire il momento in cui la sua rappresentazione diventa idonea alla ricerca.
Monitora due tempi per una coorte di importazione fissa. Uno misura la latenza delle query interattive rispetto a foto di controllo già indicizzate; l'altro misura il tempo necessario affinché le foto appena importate compaiano in ricerche prestabilite. Il primo protegge l'esperienza dell'utente attivo, mentre il secondo mostra il costo in termini di throughput della riduzione della concorrenza.
Trova il limite con un test a incrementi, non con una supposizione
Crea un lotto rappresentativo di contenuti multimediali e scegli tre ricerche fisse che restituiscano asset noti. Inizia con un worker per ogni coda attiva, esegui l'importazione e registra, nella stessa finestra di osservazione, la latenza mediana e quella della coda lenta della ricerca, la velocità di svuotamento della coda, la CPU, la pressione sulla memoria, il throughput di rete e l'attesa dello storage.
Le indicazioni generali sui colli di bottiglia raccomandano di correlare le variazioni del carico di lavoro con le attese di CPU, memoria, disco, rete e dipendenze, invece di scegliere il grafico dall'aspetto più impegnato. Aumenta un solo controllo della concorrenza per ogni esecuzione. Ripetere la stessa sequenza di ricerche e utilizzare la stessa coorte di contenuti mantiene identificabile la variabile modificata.
Fermati al primo incremento in cui il risultato obiettivo per la coda lenta della ricerca non viene raggiunto, il server inizia a usare lo swap, l'attesa dello storage rimane elevata, compaiono errori o la coda in background smette di aumentare il throughput utile. Ripeti il test dell'incremento precedente dopo un riavvio a freddo e nuovamente a caldo. Quell'incremento inferiore e ripetibile è il limite difendibile per questo carico di lavoro.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Che cos’è lo stato di Immich e quali parti devono essere persistenti?
Lo stato di Immich include gli originali, le relazioni del database, l’identità, la configurazione e i derivati; rendi persistente ciascun elemento in base alla...
Come gestisce Immich l’autenticazione tra sessioni locali e remote?
Immich utilizza un’identità gestita lato server con sessioni client, mentre gli header del proxy, le origini e i reindirizzamenti OIDC possono far variare il...
Cosa fa rallentare la ricerca o i risultati delle query in Immich con la crescita dei dati?
La crescita di Immich può ingrandire gli indici, espellere le pagine più utilizzate, complicare i filtri e ritardare la distribuzione dei contenuti multimediali; separa...
