Perché le letture e le scritture di Plex creano carichi diversi sul server

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 Reads and Writes Create Different Server Loads - Zima Store Online

Plex legge e scrive su componenti diversi del server domestico perché i trasferimenti di grandi file multimediali e i piccoli aggiornamenti dello stato hanno pattern I/O molto diversi.

Durante lo streaming, Plex può leggere in sequenza un file di grandi dimensioni mentre aggiorna contemporaneamente database, log, metadati o dati temporanei con operazioni più piccole. Questi percorsi possono condividere lo stesso dispositivo, ma reagire al carico in modo diverso. Misura separatamente il throughput dei contenuti multimediali e la latenza dei dati dell’app prima di concludere che la causa sia l’“utilizzo del disco”.

Le letture dei contenuti multimediali sono generalmente orientate al throughput

La riproduzione diretta legge grandi quantità contigue di dati multimediali e richiede soprattutto un throughput sostenuto, con margine sufficiente per gli streaming simultanei. La latenza di ricerca è meno importante rispetto a quella di un database pieno di piccoli record.

Uno storage più veloce è utile solo quando latenza, capacità e profilo delle transazioni sono adatti al carico di lavoro; i compromessi dello storage dei dati attivi rendono il pattern di accesso più significativo della sola velocità nominale del dispositivo.

Misura il throughput aggregato delle letture multimediali durante la combinazione di streaming più intensa. Se rimane molto al di sotto della capacità del dispositivo e della rete, spostare soltanto i contenuti multimediali su una memoria flash più veloce probabilmente non risolverà un ritardo nei metadati o nel database.

Le scritture dei dati dell’app sono più sensibili alla latenza

Le transazioni del database, gli aggiornamenti delle immagini, i log e i metadati generano scritture più piccole, che possono attendere la sincronizzazione, il journaling o operazioni I/O casuali concorrenti. Il loro costo percepibile può essere elevato anche quando il throughput totale in MB/s è basso.

Linux può accumulare e scaricare le pagine modificate in raffiche, quindi il writeback differito può separare il momento in cui Plex esegue la scrittura da quello in cui il dispositivo mostra un picco.

Monitora separatamente latenza, profondità della coda, memoria modificata e dispositivo dei dati dell’app rispetto al dispositivo dei contenuti multimediali. Un carico di piccole scritture con latenza elevata è un problema diverso da una lettura sequenziale dei contenuti multimediali che satura il dispositivo.

Le letture e scritture simultanee possono interferire

Collocare lo stato del database, i contenuti multimediali, i backup e i programmi di download sullo stesso dispositivo consente a pattern di accesso non correlati di competere per la stessa coda. Un’unità veloce in condizioni isolate può sembrare incostante quando questi processi si sovrappongono.

Le prestazioni del database cambiano in base sia alla velocità dello storage sia alla combinazione dei carichi di lavoro, e il comportamento dei database sensibile all’I/O è uno dei motivi per testare il carico combinato invece di estrapolare risultati da un singolo benchmark di copia file.

Ripeti un’azione lenta in Plex mettendo in pausa i processi di backup e quelli che scrivono per la gestione dei contenuti multimediali. Se la latenza crolla, separa i ruoli temporali o di storage prima di sostituire l’intero server.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

La separazione dei ruoli rende visibile il collo di bottiglia

Una topologia ordinata assegna allo stato persistente di Plex, ai contenuti multimediali in blocco, al lavoro temporaneo e ai backup ruoli distinti in termini di prestazioni e ripristino, anche quando alcuni condividono l’hardware fisico. Questo rende interpretabili i test successivi.

Separare i ruoli rende inoltre più semplice attribuire la saturazione delle risorse al dispositivo o al percorso che gestisce effettivamente il lavoro, invece di considerare lo storage come un unico pool indistinto.

Ripeti il test dopo ogni modifica ai ruoli e conserva solo i cambiamenti che spostano il collo di bottiglia misurato. In una topologia di server multimediale domestico, stato, contenuti multimediali, lavoro temporaneo e backup dovrebbero rimanere sufficientemente distinti da poter essere misurati separatamente.