Perché l’avvio di Plex diventa più lento man mano che la libreria cresce

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.

Why Plex Startup Gets Slower as a Library Grows - Zima Store Online

L’avvio di Plex può allungarsi con la crescita dello stato della libreria indicizzata, soprattutto quando il server deve esaminare, migrare o precaricare una quantità maggiore di dati del database e dei metadati.

La sola capacità dei contenuti è un indicatore poco affidabile, perché due librerie con gli stessi terabyte possono avere un numero di elementi, contenuti extra, immagini e record del database molto diversi. Tieni sotto controllo le dimensioni e la reattività della directory dei dati di Plex insieme alla durata dell’avvio. Il segnale utile è capire se la crescita dello stato indicizzato è correlata a tempi più lunghi per raggiungere la disponibilità o a query più lente.

I record indicizzati contano più della capacità dei contenuti

Una libreria con molte tracce musicali, foto, contenuti extra o episodi di piccole dimensioni può generare molto più lavoro sul database rispetto a una libreria con meno elementi ma file cinematografici più grandi. Il costo di avvio e delle query segue lo stato indicizzato, non solo i byte di origine.

Le librerie Plex di grandi dimensioni possono accumulare milioni di file e record indicizzati anche quando i soli terabyte dei contenuti sembrano gestibili; per questo la crescita degli elementi e dei record dovrebbe essere monitorata separatamente dalla capacità grezza.

Tieni traccia contemporaneamente del numero di elementi della libreria, delle dimensioni del database, delle dimensioni dei blob e dei metadati e della durata dell’avvio. Usa l’andamento del tuo server invece di adottare il numero di elementi di un altro utente come limite universale.

Le modifiche di versione possono moltiplicare il lavoro di avvio

Un normale riavvio può limitarsi a riaprire lo stato, mentre un aggiornamento può aggiungere attività una tantum che interessano molte righe esistenti. Per questo una libreria in crescita è particolarmente evidente durante le migrazioni dello schema o dei dati.

Durante le migrazioni del database, il tempo di migrazione può aumentare in base al numero di elementi indicizzati e alla velocità della CPU; perciò la durata del primo avvio dovrebbe essere distinta da quella dei normali riavvii.

Registra il tempo di riavvio di riferimento prima dell’aggiornamento e confrontalo con il primo e il secondo avvio successivi. Se il secondo avvio torna ai valori di riferimento, la libreria non è diventata permanentemente troppo grande da un giorno all’altro.

La latenza dello storage determina ancora il costo dell’accesso a piccoli stati

Un database e un albero dei metadati più grandi creano più occasioni per letture casuali, operazioni fsync e mancate corrispondenze nella cache. Un’elevata velocità di trasferimento sequenziale dei contenuti non elimina questi costi legati agli accessi di piccole dimensioni.

Quando l’avvio accede ripetutamente a piccoli elementi dello stato, la latenza di avvio su SSD rispetto a HDD può modificare il momento in cui il servizio diventa disponibile, anche quando il runtime del container è identico.

Colloca lo stato di Plex in un’area con latenza prevedibile, quindi misura prima e dopo. Il percorso persistente dei dati dell’app dovrebbe essere ottimizzato per lo stato del server, mentre i contenuti di grandi dimensioni possono rimanere su uno storage orientato alla capacità.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Un andamento delle query in rallentamento è un indicatore migliore per un aggiornamento

Il limite pratico emerge quando le operazioni comuni di navigazione, ricerca, avvio o manutenzione non raggiungono ripetutamente l’obiettivo in condizioni di database integro. Aggiungere hardware è utile solo se il carico di lavoro è effettivamente limitato da quell’hardware.

I lunghi tempi delle operazioni sul database sono un indicatore migliore per isolare il percorso dello stato, invece di considerare ogni avvio lento come un problema generale di lentezza dell’host.

Registra un piccolo insieme di attività ripetibili — riavvio fino alla disponibilità, apertura della libreria, ricerca e manutenzione del database — e seguilo nel tempo. Esegui l’aggiornamento quando un percorso misurato peggiora in modo costante, non quando la libreria supera una dimensione arbitraria.