Cosa fa rallentare la ricerca o i risultati delle query in Immich con la crescita dei dati?
La ricerca in Immich rallenta con la crescita quando gli indici più grandi e i working set superano la capacità di cache, filtraggio o gestione dello storage efficiente, non semplicemente perché esistono più foto.
Una libreria più grande aumenta contemporaneamente diverse quantità: righe, embedding, metadati, miniature e possibili combinazioni di filtri. Diagnostica la fase che rallenta, perché uno storage più veloce non può correggere un percorso di query inefficiente, mentre l’ottimizzazione del database non può accelerare un mount remoto delle miniature.
La crescita amplia più della libreria originale
Ogni risorsa aggiunta può contribuire con righe del database, metadati estratti, rappresentazioni per la ricerca, volti, miniature e contenuti multimediali codificati. Queste strutture crescono a ritmi diversi e vengono utilizzate in modo differente. I terabyte della libreria originale, quindi, non possono prevedere la latenza della ricerca senza sapere quante entità ricercabili e quanti oggetti derivati attraversa la richiesta.
L’analisi del percorso dei dati di Immich di ZimaSpace separa l’elaborazione in background, le rappresentazioni ricercabili, la selezione del database e i contenuti multimediali forniti. La lezione pratica per la diagnosi delle query è che la crescita della libreria modifica sia il catalogo ricercabile sia i file presentati dopo un risultato, creando più di una possibile fonte di ritardo.
Registra il numero di risorse, le dimensioni del database e dell’indice vettoriale, lo spazio occupato dalle miniature e la cardinalità dei filtri usati più spesso a ogni traguardo. Una serie temporale mostra quale struttura cresce insieme alla latenza e impedisce di attribuire a un aumento non correlato dei gigabyte dei video originali il tempo di selezione del database.
Gli indici vettoriali diventano sensibili alla disponibilità di memoria
La ricerca semantica attraversa un indice delle rappresentazioni invece di leggere ogni immagine originale. Quando l’indice cresce, il grafo attivo o le sue pagine potrebbero non rimanere più residenti in memoria. I cache miss casuali trasformano così il lavoro alla velocità della memoria in letture dallo storage, facendo aumentare la latenza di coda più rapidamente di quanto suggerisca l’utilizzo medio della CPU.
Un’analisi tecnica della ricerca vettoriale in PostgreSQL spiega che le prestazioni di HNSW possono peggiorare quando il grafo attivo supera la memoria disponibile, perché l’attraversamento ad accesso casuale diventa sensibile ai cache miss. Le versioni di Immich e le implementazioni degli indici possono cambiare, quindi usa questo elemento come meccanismo da verificare, non come prescrizione di configurazione.
Misura una query semantica fissa dopo il riavvio, dopo un singolo riscaldamento e dopo aver toccato regioni non correlate della libreria. Confronta le letture del database, il comportamento della cache e la latenza del dispositivo. Forti miglioramenti dopo il riscaldamento che scompaiono quando il working set si amplia supportano l’ipotesi di una memoria insufficiente; query uniformemente lente indicano un problema diverso.
I filtri e i piani di query possono cambiare con la cardinalità
Data, persona, proprietario, album e altre condizioni modificano il numero di candidati rimasti prima o durante il ranking. Quando cambia la distribuzione dei dati, lo stesso filtro visibile può selezionare una frazione molto più ampia della libreria. Le statistiche del database e la scelta del piano possono quindi diventare determinanti anche quando il termine di ricerca non cambia.
Una revisione delle limitazioni di pgvector osserva che combinare la ricerca vettoriale con i filtri sui metadati può essere difficile e che i carichi vettoriali condividono CPU, memoria e I/O di PostgreSQL con il lavoro transazionale. L’articolo fornisce prove generali su PostgreSQL, quindi supporta il meccanismo senza dimostrare uno specifico piano di query di Immich.
Crea ricerche appaiate, con e senza un filtro, usando set di risultati noti. Acquisisci i tempi delle query lato server e l’attività del database, non solo il completamento nel browser. Se il tempo di selezione cresce mentre le miniature restituite rimangono rapide, concentrati su piani, statistiche, adeguatezza degli indici e contesa invece che sullo storage dei contenuti multimediali.
Separa la selezione dei risultati dal rendering
L’interfaccia può sembrare lenta dopo che il database ha già selezionato gli identificativi delle risorse corrispondenti. Il rendering richiede comunque la ricerca delle miniature, letture dallo storage, trasferimento della risposta e decodifica sul client. Un albero di file derivati in crescita o un mount remoto può ritardare questa seconda fase mentre la query effettiva di ricerca rimane efficiente.
Un resoconto di una grande importazione descrive una lentezza generalizzata in Immich mentre centinaia di migliaia di attività sui metadati e sulle miniature erano ancora in coda. Dimostra una pressione sovrapposta delle attività in background, non un limite universale di scalabilità, e mostra perché i test di crescita dovrebbero essere eseguiti sia con le code attive sia dopo il loro svuotamento.
Usa i tempi del browser o le osservazioni dell’API per distinguere il completamento della risposta dei risultati dall’ultima miniatura visibile. Ripeti una ricerca nota con le code in pausa e poi con le code attive. Se gli identificativi rallentano, esamina i percorsi del database e degli indici; se rallentano solo le immagini, controlla lo storage delle miniature, la distribuzione di rete, la decodifica del client e l’I/O in background concorrente.
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...
Perché Immich si comporta diversamente dopo il riavvio di un container?
Dopo il riavvio di Immich, è prevista una perdita temporanea della cache; cambiamenti persistenti nell’accesso, nel database o nei contenuti multimediali indicano problemi di...
