In che modo il posizionamento del database influisce sull’affidabilità e sul ripristino di Plex

L'affidabilità di Plex generalmente migliora quando il database attivo e i metadati rimangono su uno storage locale a bassa latenza, mentre i contenuti multimediali possono risiedere altrove.

Un server Plex può trasmettere film da grandi HDD o da uno storage di rete, mentre i dati dell'applicazione eseguono numerose letture e scritture di piccole dimensioni su un percorso diverso. Questa distinzione è importante perché un file multimediale contiene per lo più dati sequenziali, mentre il database della libreria, i metadati, le miniature e i log si comportano più come lo stato dell'applicazione. Considera il posizionamento del database come una decisione relativa a latenza e ripristino, non alla capacità.

Perché il database di Plex si comporta diversamente dai file multimediali

La directory dei dati di Plex contiene il database della libreria, oltre a metadati, immagini, cache e altri dati di stato del server. Questi file vengono utilizzati durante la navigazione, le scansioni, l'elaborazione dei metadati, gli aggiornamenti dello stato di riproduzione e le attività di manutenzione; perciò, i picchi di latenza sul percorso dei dati dell'applicazione possono far sembrare inaffidabile l'intero server, anche quando i file dei film vengono letti rapidamente.

Plex conserva lo stato della libreria utilizzato più frequentemente in un database SQLite, quindi la latenza e l'integrità del database dovrebbero essere valutate separatamente rispetto al throughput dei contenuti multimediali; questo è il punto di partenza da stabilire per il posizionamento e il ripristino del database.

Il comportamento osservabile è semplice: se la navigazione, gli aggiornamenti della libreria e l'avvio sono lenti mentre la riproduzione diretta di un file già aperto è regolare, il percorso dei dati dell'applicazione merita attenzione prima dei dischi che contengono i contenuti multimediali.

Misura latenza e ripristino, non solo il throughput

Le variabili importanti sono la latenza dell'I/O casuale, la stabilità del filesystem, lo spazio libero, la durabilità delle scritture e il comportamento dei backup. Il throughput sequenziale di picco è secondario, perché il database non si comporta come un grande flusso video.

Quando misuri il posizionamento e il ripristino del database, un controllo dei colli di bottiglia risorsa per risorsa dovrebbe esaminare utilizzo, saturazione ed errori di CPU, memoria, rete e storage, invece di basarsi su un'unica metrica media.

Se lo spostamento dei dati dell'applicazione riduce i tempi di avvio e le pause durante le scansioni senza modificare il throughput della riproduzione multimediale, hai isolato un collo di bottiglia nei metadati o nel database, non nello storage dei contenuti.

Quando uno storage più veloce smette di essere utile

Un SSD locale non risolve la transcodifica limitata dalla CPU, la larghezza di banda di upload saturata, i codec non supportati dal client o un disco multimediale in avaria. Quando la latenza del database è sufficientemente bassa da lasciare che siano queste altre fasi a dominare, aggiungere IOPS al dispositivo che contiene i dati dell'applicazione offre rendimenti decrescenti.

Al limite del guasto relativo al posizionamento e al ripristino del database, quando la corruzione è reale, il ripristino è più sicuro se crea un nuovo database SQLite integro a partire dai dati recuperabili, invece di modificare ripetutamente l'originale danneggiato.

Il test di confine consiste nel confrontare l'integrità del database e lo spazio libero con la tempistica del problema. Se l'integrità è buona e la latenza dei dati dell'applicazione è bassa, sposta l'indagine su CPU, rete, compatibilità del client o percorso dei contenuti multimediali, invece di aggiornare nuovamente lo storage.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Usa un test di posizionamento in quattro passaggi

Mantieni il percorso dei dati dell'applicazione Plex su un filesystem locale persistente, conserva un backup aggiornato e tratta i contenuti multimediali come un livello di capacità separato. Poi esegui il benchmark di un'azione ripetibile della libreria prima e dopo ogni modifica al posizionamento. Un layout dello storage per un server multimediale domestico è più facile da valutare quando i ruoli di elaborazione, dati dell'applicazione, storage multimediale e rete sono descritti separatamente.

Prima di accettare una modifica al posizionamento e al ripristino del database, un backup SQLite coerente dovrebbe provenire da un flusso di backup o snapshot sicuro, non da una copia non controllata dei file del database attivo durante le scritture.

Smetti di ottimizzare il dispositivo del database quando il test ripetuto non modifica più il comportamento di avvio, navigazione o scansione. A quel punto, la misurazione successiva più utile riguarda la fase che continua a consumare tempo con lo stesso carico di lavoro.

1. Verifica che la directory dei dati di Plex sia persistente e disponga di spazio libero
2. Misura l'avvio e una scansione della libreria prima di modificare lo storage
3. Sposta solo i dati dell'applicazione, non tutti i file multimediali, per effettuare il confronto
4. Verifica i percorsi di backup e ripristino prima di dismettere la vecchia posizione