So erkennen Sie, ob Plex durch CPU, RAM, Speicher oder Netzwerk eingeschränkt wird

Sie können feststellen, was Plex begrenzt, indem Sie eine bekannte Arbeitslast reproduzieren und nach der Ressource suchen, deren Auslastung gleichzeitig mit der Verlangsamung des Streams steigt. Rüsten Sie nicht zuerst die Komponente mit der höchsten Auslastung auf; eine hohe Auslastung ist nur dann relevant, wenn sie zeitgleich mit dem Wiedergabefehler auftritt.

Beginnen Sie mit einer Datei, einem Client, einem Wiedergabemodus und einem Zeitfenster. Trennen Sie anschließend die Konvertierungsarbeit von Plex von den Signalen des Betriebssystems für CPU, Arbeitsspeicher, Speicher und Netzwerk. Der Test ist erst abgeschlossen, wenn die Änderung einer vermuteten Ressource das ursprüngliche Plex-Symptom verändert, während die übrigen Bedingungen stabil bleiben.

Reproduzieren Sie eine Plex-Arbeitslast, bevor Sie Systemmetriken auswerten

Wählen Sie eine Datei und einen Client, mit denen sich das Problem zuverlässig reproduzieren lässt. Notieren Sie, ob es sich um einen langsamen Start, wiederholtes Puffern, eine zurückfallende Transkodierung, einen Scan handelt, der die Wiedergabe verzögert, oder um einen Fehler, der nur aus der Ferne auftritt, da jedes Symptom auf einen anderen Wartepfad hindeutet.

Ein Plex-spezifischer Ablauf zur Fehlerbehebung sollte mit der aktiven Sitzung statt mit einem allgemeinen CPU-Diagramm beginnen. Eine praktische Dashboard-basierte Prüfung trennt die Zweige Direct Play, Transkodierung, Netzwerk und Speicher, bevor Sie Änderungen am Server vornehmen.

Lassen Sie Datei, ausgewählte Tonspuren, Client-Qualität und parallele Arbeitslast unverändert, während Sie Systemmetriken erfassen. Wenn sich das Symptom zwischen den Tests verschiebt, vereinfachen Sie die Arbeitslast, bis derselbe Fehler wiederholt auftritt; andernfalls kann ein späterer CPU- oder Festplattenpeak zu einem anderen Prozess gehören.

Die Plex-Sitzung verwenden, um Übertragung und Konvertierung zu trennen

Lesen Sie die Plex-Sitzung, während das Problem auftritt. Direct Play bedeutet, dass der Server hauptsächlich die gespeicherten Mediendaten ausliefert, während eine Videotranskodierung einen echten Echtzeit-Konvertierungspfad hinzufügt, der den Engpass zur CPU oder zu Hardware-Videoengines verlagern kann.

Verwenden Sie diesen Modus als Entscheidungspunkt, nicht als Schlussfolgerung. Eine zurückfallende Transkodierung macht die Rechenleistung zu einem starken Kandidaten, aber auch bei puff­erndem Direct Play kommen Speicher und Netzwerk weiterhin infrage. Wenn dieselbe Datei den Modus wechselt, sobald sich Untertitel, Audio oder Qualität ändern, reproduzieren Sie das Problem erneut mit der ursprünglichen Anfrage, bevor Sie Host-Metriken vergleichen.

Am Ende dieses Abschnitts sollte ein fester Wiedergabemodus stehen, der eindeutig mit dem Symptom verknüpft ist. Wenn Sie nicht angeben können, ob der fehlschlagende Test Direct Play oder Transcode verwendet, halten Sie hier an; der Vergleich von RAM-, Festplatten- und Netzwerkdaten vor der Stabilisierung des Medienpfads erschwert die Interpretation der übrigen Metriken.

CPU- und RAM-Auslastung gemeinsam testen

Beobachten Sie während des festgelegten Plex-Tests die CPU-Auslastung, die Run-Queue oder Last, den verfügbaren Arbeitsspeicher und die Swap-Aktivität. CPU-Druck ist besonders aussagekräftig, wenn der Plex-Prozess oder dessen Transcoder dauerhaft Rechenleistung verbraucht, während die Ausgabe zurückfällt. Speicherdruck ist wahrscheinlicher, wenn das System beginnt, Speicher zurückzugewinnen oder auszulagern, und sich die Reaktionszeit verschlechtert, obwohl die CPU nicht die einzige ausgelastete Ressource ist.

Ein allgemeiner Linux-Workflow zur Leistungsanalyse verwendet Werkzeuge wie top, vmstat, iostat und sar, um Ressourcendruck voneinander zu trennen. Insbesondere benötigen CPU, Arbeitsspeicher, Festplatte und Netzwerk unterschiedliche Sättigungssignale statt einer einzigen Gesamtauslastungszahl.

Bleibt die CPU nur während der fehlschlagenden Transkodierung nahe ihrer Grenze und erholt sich der Stream, sobald die Konvertierung entfernt oder beschleunigt wird, betrachten Sie die Rechenleistung als führenden Engpass. Steigen stattdessen Auslagerung oder Speicher-Rückgewinnung an, reduzieren Sie parallele speicherintensive Aufgaben oder erweitern Sie den Arbeitsspeicher. Wiederholen Sie anschließend dieselbe Plex-Arbeitslast, bevor Sie Einstellungen für Speicher oder Netzwerk ändern.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Den Speicherpfad mit derselben Medienverarbeitung testen

Lesen Sie zur Speicheranalyse dieselben Mediendaten vom selben Dateisystem, während das Symptom reproduziert wird, und beobachten Sie Geräte-Latenz, Warteschlangen und I/O-Wait. Kapazität und Leistung sind zwei verschiedene Dinge: Eine Festplatte kann freien Speicherplatz haben und dennoch langsam reagieren, weil ein anderer Prozess zufällige I/O-Vorgänge erzeugt oder der Medienpfad über einen ausgelasteten Pool oder eine Netzwerkfreigabe läuft.

Linux-Werkzeuge wie iostat und iotop sind nützlich, da Festplatten-I/O-Wait und Gerätedurchsatz einen anderen Fehlermodus sichtbar machen als hohe CPU- oder Swap-Aktivität. Vergleichen Sie diese Werte mit dem genauen Pufferintervall und nicht mit einem Durchschnitt im Leerlauf.

Wenn die Datei sauber gelesen wird, während Plex puffert, ist der Speicher weniger wahrscheinlich die Ursache. Steigen Latenz und Warteschlangen gemeinsam mit dem Symptom an, pausieren Sie den konkurrierenden Festplattenprozess oder verschieben Sie die Testdatei auf einen bekanntermaßen schnellen lokalen Pfad. Erholt sich Plex im selben Wiedergabemodus sofort, ist aus dem Speicherverdacht ein Beleg geworden.

Den Netzwerkdurchsatz auf dem tatsächlichen Pfad testen

Testen Sie den Pfad zwischen Server und Client unabhängig von Plex. Ein lokaler kabelgebundener Client kann ein Problem der Remote-Route von einem serverweiten Ressourcenproblem unterscheiden, während ein Ende-zu-Ende-Durchsatztest zeigen kann, ob der Pfad die Medienrate ohne Abhängigkeit von der Plex-Anwendung aufrechterhalten kann.

Verwenden Sie ein Werkzeug wie iperf3, wenn Sie beide Enden kontrollieren. Ein Netzwerktest sollte Durchsatz, Paketverlust und Latenz untersuchen, denn eine angegebene Verbindungsgeschwindigkeit beweist nicht, dass die tatsächliche Route stabilen Anwendungsverkehr liefert.

Wenn der unabhängige Netzwerktest einbricht, während CPU, Arbeitsspeicher und Speicher unauffällig bleiben, beheben Sie zuerst den Netzwerkpfad, bevor Sie den Transcoder optimieren. Verfügt das Netzwerk über ausreichend dauerhafte Reserven und besteht das Plex-Symptom bei einem kabelgebundenen lokalen Test weiterhin, kehren Sie zum Zweig der Serverressourcen zurück, statt einen schnelleren Router zu kaufen.

Nur die Ressource ändern, die den Test nicht bestanden hat

Wählen Sie die erste Ressource, die bei einem Ausschlusstest versagt hat, und nehmen Sie eine Änderung vor, die nur diesen Zweig beeinflussen sollte. Beispiele sind das Aktivieren einer verifizierten Hardware-Transkodierung für einen rechengebundenen Stream, das Reduzieren einer speicherintensiven Hintergrundaufgabe, das Verschieben eines festplattenintensiven Prozesses oder das Umgehen eines schwachen Netzwerkabschnitts.

Für eine Plex-spezifische Fortsetzung bietet der Diagnosepfad gegen Pufferprobleme von ZimaSpace eine ausführlichere Anleitung, sobald Sie wissen, ob Wiedergabemodus, Konvertierungslast, Netzwerkstabilität oder Speicherreaktionszeit der zu ändernde Zweig ist.

Wiederholen Sie nach der Änderung den Test mit derselben Datei, demselben Client und demselben Wiedergabemodus. Bezeichnen Sie eine Komponente nur dann als Engpass, wenn sich das ursprüngliche Symptom verbessert und das passende Auslastungssignal sinkt oder zusätzliche Reserven entstehen. Bleibt das Symptom unverändert, stellen Sie den Ausgangszustand wieder her und testen Sie den nächsten Zweig, statt Upgrades zu stapeln, bis die eigentliche Ursache zufällig verschwindet.