Waarom lezen en schrijven met Plex verschillende serverbelastingen veroorzaken

Plex leest en schrijft in verschillende delen van een thuisserver, omdat grote mediaoverdrachten en kleine statusupdates zeer verschillende I/O-patronen hebben.

Een stream kan een groot bestand sequentieel lezen terwijl Plex tegelijkertijd databases, logboeken, metagegevens of tijdelijke gegevens in kleinere bewerkingen bijwerkt. Deze paden kunnen één apparaat delen, maar verschillend reageren op belasting. Meet de mediadoorvoer en de latentie van app-gegevens afzonderlijk voordat je concludeert dat “schijfgebruik” de oorzaak is.

Media lezen is meestal gericht op doorvoer

Direct afspelen haalt grote, aaneengesloten mediagegevens op en heeft vooral een aanhoudende doorvoer nodig met voldoende marge voor gelijktijdige streams. Zoeklatentie is hierbij minder belangrijk dan bij een database met veel kleine records.

Snellere opslag helpt alleen wanneer de latentie, capaciteit en transactiekenmerken ervan bij de werklast passen; afwegingen rond opslag van actieve gegevens maken het toegangspatroon nuttiger dan alleen de nominale snelheid van het apparaat.

Meet de totale doorvoer voor het lezen van media tijdens de drukste combinatie van streams. Als die ruim onder de capaciteit van het apparaat en het netwerk blijft, zal alleen het verplaatsen van media naar sneller flashgeheugen een vertraging in metagegevens of de database waarschijnlijk niet oplossen.

Schrijven van app-gegevens is gevoeliger voor latentie

Databasetransacties, updates van illustraties, logboeken en metagegevens veroorzaken kleinere schrijfbewerkingen die kunnen wachten op synchronisatie, journaling of concurrerende willekeurige I/O. De zichtbare impact kan groot zijn, zelfs wanneer de totale MB/s laag is.

Linux kan vuile pagina’s in bursts verzamelen en wegschrijven, waardoor uitgesteld terugschrijven het moment waarop Plex schrijft kan loskoppelen van het moment waarop het apparaat een piek laat zien.

Houd de latentie, wachtrijdiepte, het aantal vuile geheugenpagina’s en het apparaat voor app-gegevens afzonderlijk bij van het media-apparaat. Een kleine schrijfwerklast met hoge latentie is een ander probleem dan een verzadigde sequentiële media-uitlezing.

Gelijktijdig lezen en schrijven kan elkaar hinderen

Door databasestatus, media, back-ups en downloadprogramma’s op één apparaat te plaatsen, laat je niet-gerelateerde toegangspatronen concurreren om dezelfde wachtrij. Een schijf die afzonderlijk snel is, kan inconsistent aanvoelen wanneer deze taken elkaar overlappen.

Databaseprestaties veranderen door zowel de opslagsnelheid als de samenstelling van de werklast, en I/O-gevoelig databasegedrag is een reden om de gecombineerde werklast te testen in plaats van te extrapoleren uit één benchmark voor het kopiëren van bestanden.

Herhaal een trage Plex-actie terwijl back-ups en schrijfbewerkingen van mediabeheer zijn gepauzeerd. Als de latentie sterk afneemt, scheid dan de timing of opslagrollen voordat je de hele server vervangt.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Rollen scheiden maakt de bottleneck zichtbaar

Een overzichtelijke topologie geeft permanente Plex-status, bulkmedia, tijdelijk werk en back-ups afzonderlijke prestatie- en herstelrollen, zelfs wanneer sommige rollen fysieke hardware delen. Daardoor zijn latere tests beter te interpreteren.

Door rollen te scheiden wordt het ook eenvoudiger om verzadiging van resources toe te wijzen aan het apparaat of pad dat het werk daadwerkelijk uitvoert, in plaats van aan opslag als één ongedifferentieerde pool.

Test opnieuw na elke rolwijziging en behoud alleen wijzigingen die de gemeten bottleneck verplaatsen. In een topologie voor een mediaserver thuis moeten status, media, tijdelijk werk en back-ups voldoende van elkaar gescheiden blijven om ze onafhankelijk te kunnen meten.