Ich habe gerade Plex und MCEBuddy auf einem AMD 16-Kern-Prozessor Ryzen installiert, und es läuft mit 8 gleichzeitigen Verbindungen. Wenn ich den Prozessor mit Process Lasso beobachte, liegt die Auslastung unter 50 %, oft nur bei 20 % und gelegentlich bis zu 55 %. Gibt es einen Grund, warum ich nicht mehr gleichzeitige Konvertierungen durchführen kann, oder ist das nur eine GUI-Begrenzung?
Die Maschine hat eine M.2 Samsung SSD, und beim Schreiben der Ausgabedatei erreicht sie intern 350 Megabyte pro Sekunde, das dauert aber nur etwa eine Sekunde. Die 16 GB RAM sind nur zu etwa 40 % belegt, also hat das System insgesamt locker die doppelte Rechenleistung, soweit ich das beurteilen kann.
Nur GUI, aber ich kann dir sofort sagen, dass etwas nicht stimmt. 8 gleichzeitige Konvertierungen können selbst die größten Systeme mit den größten Grafikkarten, die wir gesehen haben, vollständig auslasten.
Wenn selbst eine einzelne Datei mit softwarebasierten Konvertierungen konvertiert wird, sollte die CPU bei 100 % liegen (MCEBuddy ist mehrfädig). Dies wäre jedoch nur während der eigentlichen Konvertierung und nicht bei anderen Aktivitäten (wie Remuxing und Analyse usw.). Welches Profil verwendest du, ist Hardware-Encoding aktiviert (NVIDIA oder Intel), und betrachtest du die CPU-Auslastung während der Konvertierungsphase?
Ich habe eine Asus GTX 1070 TI, die etwa auf dem Niveau einer typischen 1080 getaktet ist, aber 15 % weniger Cores bietet. Hardware-Encoding ist lt. Log aktiv und funktioniert.
Das Profil lautet „Convert to MKV Normal Quality“. Ich habe die Plex-Integration eingerichtet, lasse dabei aber die komplette Videothek (ca. 6500 Titel) auf Werbung untersuchen und entferne diese sowie komprimiere größere Dateien (z. B. MP2).
Ich habe die CPU-Auslastung länger beobachtet (30-Minuten-Logs), um die Spitzen zu identifizieren. Mit Abstand intensivster Prozess ist ffmpeg: pro Instanz 32–49 Threads, Mencoder bringt 9–12 Threads, Comskip immer 7 Threads.
Threads laufen auf jedem Core (außer dem letzten, den ich in Process Lasso für Plex reserviert habe) und sind gut verteilt. Dennoch scheint etwas die Gesamtauslastung zu bremsen – vermutlich fehlende Parallelität beim „Analyzing Video Information“. Ich nehme an, das passiert innerhalb ffmpeg, denn dort sind gerade 7 Instanzen aktiv (plus ein Comskip); dabei ist die CPU-Auslastung am geringsten.
Interessant: Senke ich die parallelen Sessions von 8 auf 6, fällt die Gesamtauslastung um etwa 30 % (von etwas über 50 % auf gut 35 %). Darum fragte ich, warum nicht 12 oder 16 Sessions – evtl. ein Lock-Problem (Spinlock).
Insgesamt werden rund 800 Videos pro Tag verarbeitet – das ist ziemlich flott – und die Ergebnisse sind in Ordnung (bis auf gelegentliche Audio/Video-Sync-Probleme nach Comskip).
Bei 8 gleichzeitigen Sitzungen sind das fast 400 Threads, und es bringt die CPU nicht ans Limit – ich bin beeindruckt. Probier das: Erstelle ein eigenes Profil und füge den Parameter -threads 100 oder wie viele Threads auch immer du möchtest ein, und schau, ob das einen Unterschied macht.
Bei Comkip stellst du die Thread-Anzahl glaube ich in der INI-Datei ein – bin mir nicht sicher, aber du kannst das im Diskussionsforum nachlesen.
Schau mal, ob sich damit die CPU-Auslastung erhöht. Was die Anzahl gleichzeitiger Konvertierungen betrifft: Wenn du noch mehr willst, stoppe einfach die Engine, öffne die Datei mcebuddy.conf, setze die maximale Anzahl gleichzeitiger Konvertierungen auf den gewünschten Wert (12 oder 16) und speichere die Datei. Dann klicke auf Start, damit die Einstellungen neu geladen werden (öffne nur nicht den Reiter Einstellungen und klicke auf Speichern, da sonst eine Ausnahme ausgelöst wird). Wenn das dein Problem löst, erhöhen wir in der nächsten Version die maximale Anzahl gleichzeitiger Konvertierungen.
Eine weitere Sache ist, dass es bei „Analysiere Videoinformationen“ und wenn sich Müll in der Videodatei befindet (vom Antenne aufgenommen, daher sind manche Dateien nicht hochwertig), sehr lange (vielleicht für immer, obwohl ich es nie länger als einen Tag habe hängen lassen) dabei hängen bleibt. Das ist ein weiterer Grund, warum ich dachte, dass es gut wäre, mehr Sessions zu haben, damit, wenn einige davon hängen bleiben, andere weitermachen können.
Wenn sie hängen bleiben, notiere ich mir den Namen, stoppe die Konvertierungen, lösche die Dateien und starte neu. Irgendwann verstopft es sich wieder mit weiteren.
Laden Sie die Datei, die „hängenbleibt“, hoch, damit wir analysieren können, was vor sich geht. Während der Analysephase passieren mehrere Dinge, darunter die Analyse der technischen Eigenschaften der Spur zur Einrichtung/Optimierung der Konvertierung sowie das Durchlaufen des gesamten Videos zur Suche nach Zuschnitt-Informationen. Falls das Zuschneiden das Problem verursacht, aktivieren Sie das Kästchen in den Experteneinstellungen, das „Zuschneiden deaktivieren“ besagt, und dieser Schritt wird übersprungen. Aber laden Sie auf jeden Fall hoch, damit wir uns das ansehen können.
ich glaube, ich habe eine Ursache gefunden: Bitdefender untersuchte offenbar alles, was auf die Platte geschrieben wurde, und war dabei überfordert. Nachdem ich es angewiesen habe, Disk-I/O von allem, was mit der Videoverarbeitung zu tun hat, zu ignorieren, stieg die Auslastung um 25 %. Die CPU-Last liegt jetzt bei etwa 80 % Spitze, durchschnittlich 70 % und fällt bis auf 50 %. Nicht perfekt, aber deutlich besser. Ich prüfe gerade, ob Windows Defender ebenfalls Ressourcen blockiert und ob ich es ausschalten kann.
Danke für die weiteren Infos – ich werde die Thread-Anzahl für ffmpeg erhöhen und schauen, was passiert. Ich wette, ich kann auf 100 % kommen.
Du bist auf dem richtigen Weg, bei 8 parallelen Konvertierungen ist möglicherweise die langsamste Verbindung der Flaschenhals, wie deine Festplatte. Versuche, die Konvertierungsaufgaben auf verschiedene Ziel- und Quellplatten zu verteilen, lege den Temp-Ordner auf ein RAM-Laufwerk, falls du zusätzlichen RAM-Speicher hast, und du wirst einen ENORMEN Geschwindigkeitsschub bei deiner Verarbeitung feststellen.
Danke für deine Gedanken. Ich habe eine M.2-Samsung-512-GB-NVMe-SSD (mit 8 Gb/s) nur für die Temp-Dateien und eine für Win 10 und Plex. Die Bibliothek liegt auf einem RAID-5-Plattenverbund mit acht 4-TB-Spindeln, sodass die I/O-Warteschlange (ich sehe maximal 1000 ausstehende I/Os) beim Vollbetrieb recht klein ist und in Millisekunden abgearbeitet wird. Im Moment sehe ich über 350 Megabyte pro Sekunde (in zweisekündigen Burst-Phasen), was für mich ernsthafter I/O ist.
Ich habe ein RAM-Disk mit 8 GB als Temp-Laufwerk getestet; außer dass bei Volllast der Speicher knapp wurde, war sie etwa so schnell wie die M.2-Platten. Also gab ich dem Betriebssystem wieder alle 16 GB zurück.
Ich denke, ich bin auf Kurs, bis zu 1200 Videos pro Tag zu verarbeiten – das reicht für meinen persönlichen PLEX-Server völlig aus. Die Engpässe habe ich identifiziert und werde die Thread-Anzahl für ffmpeg erhöhen.
Yup. Wird das also in der GUI sein? Wird der Bereich, der den Status anzeigt, in einem scrollbaren Bereich sein, wie die Dateiverarbeitungsliste darüber?
Ja, der Hauptbildschirm erhält eine Bildlaufleiste, wenn mehr Warteschlangen vorhanden sind, als auf dem Bildschirm dargestellt werden können. Die Standard-Dropdown-Optionen sind weiterhin 1 bis 8, aber Sie können sie manuell bis auf 50 überschreiben; allerdings benötigen Sie dafür eine enorme Menge an freiem Speicherplatz im Temp-Ordner (1,5 × Anzahl der Konvertierungen × Dateigröße), um so viele gleichzeitige Konvertierungen zu nutzen.
Thomweah5555, welche Einstellungen hast du in Bitdefender geändert? Unter Tools – Erweitert sehe ich einige Dinge, die gemeint sein könnten.
Kannst du uns in die richtige Richtung weisen?
Danke
Entschuldigung, der Hauptverursacher war ByteFence, für das ich die Temp- und Video-Laufwerke auf die Whitelist gesetzt habe. Aber bei Bitdefender hilft es, den Autopiloten zu deaktivieren.