staging.inyokaproject.org

Ich bin seit einigen Tagen dabei meine Videosammlung mit ffmpeg zu reencoden. Aber trotz nice und ionice ruckeln meine anderen Anwendung wenn ich z.B. im Browser surfe. Habe zuerst nur nice und später auch ionice ausprobiert - es hilft nichts. Mein Script beginnt mit:

nice -n 19 ionice -c3 ffmpeg ...

Was mache ich falsch? 😐

Hallo,

was nutzt du denn für Hardware? Und was läuft noch auf dem Rechner aus ffmpeg und der Browser?

Gruß, noisefloor

dentaku schrieb:

nice -n 19 ionice -c3 ffmpeg ...

Ich würde mal annehmen, dass ffmpeg CPU bound und nicht IO bound ist. Von daher kannst Du Dir den ionice vermutlich sparen. Du könntest auch mal auf die Optionen -filter_threads und -filter_complex_threads von ffmpeg schauen. Z.B. um die Hälfted der Kerne zu nutzen:

1
2

threads=$(( $(lscpu --parse=CPU | egrep -cv '^#') / 2))
ffmpeg ... -filter_threads $threads -filter_complex_threads $threads ...

rklm schrieb:

1	threads=$(( $(lscpu --parse=CPU | egrep -cv '^#') / 2))

Ich würde dafür nproc nehmen, zum Beispiel

1

threads=$(nproc --ignore=2)

um zwei Kerne frei zu lassen.

Hab'nen Quadcore aber weder "-threads 3" noch "-threads (nproc --ignore=2)" noch "-filter_threads 3" helfen: es werden immer alle 100% genutzt und das wird auch in der Konsole angezeigt:

x265 [info]: Thread pool created using 4 threads

"Witzig": habe nun spezielle libx265 angegeben bei denen sich etwas verändert:

... ffmpeg ... -c:v libx265 -x265-params "frame-threads=2:pools=2" ...

Die Systemüberwachung zeigt damit eine Auslastung von 50% CPU und die 4 corse springen immer zwischen "0 und 100". Das "witzige" daran: es hat sich praktisch nichts von der Performance verändert: das encoding ist etwas langsamer (wie erwartet), aber der Browser ruckelt trotzdem. ☹

Was für eine CPU hast du denn? Vier physikalische Kerne oder zwei Kerne mit Hyperthreading?

Quadcore (AMD A10-7850K)

Hm, bei den älteren AMD-Prozessoren (vor Zen) teilen sich jeweils zwei Kerne eine FPU und weitere Teile des Prozessors. Das könnte erklären, warum das restliche System beeinflusst wird.

Du könntest mal versuchen, mit taskset den ffmpeg-Prozess auf jeweils zwei Kerne zu begrenzen. Wenn du zwei triffst, die in einem CMT-Modul sind, sollte sich die Encoding-Performance deutlich verändern und der Browser vom Kernel auf das andere Modul gelegt werden und nicht mehr ruckeln.

To the best of my knowledge. Bitte korrigiert mich, wenn das schon wieder veraltet ist.

Benutzt du den Kernel-Parameter noautogroup? Wahrscheinlich nicht.

Der zu erwartende Effekt mit Autogroup ist eigentlich der:

• Browser ist eine Task-Gruppe

• Terminal ist eine Task-Gruppe, alle ffmpeg-Prozesse/-Threads sind in dieser Gruppe

• Scheduling geht zuerst über die Gruppen und dann passiert Nice nur innerhalb der Gruppen

Heißt, Browser kriegt 50% der CPU-Zeit und das Terminal mit ffmpeg die anderen 50%. Wenn im Terminal nix anderes als ffmpeg läuft, dann hat dein Nice also genau gar keinen Effekt.

Eigentlich sollte dieses Autogrouping dafür sorgen, dass du dich nicht mehr mit Nice „rumschlagen“ „musst“. Browser und ffmpeg sollen ja jeweils 50% der Zeit kriegen – und zwar unabhängig davon, ob ffmpeg jetzt 64 Threads startet oder nur einen. Das ffmpeg soll deinen Browser nicht mehr lahmlegen können.

Du kannst uns mal die Ausgabe von „grep ' /autogroup' /proc/sched_debug“ posten in so einer Situation, in der dir was komisch vorkommt (ffmpeg läuft, Browser ruckelt). Vielleicht ist das aufschlussreich. Und ein Blick auf die Anzeige in htop wäre auch noch interessant.

Was du natürlich auch mal blind versuchen kannst, ist, mit noautogroup zu booten und die Situation dann zu begutachten. Nice hat dann im Hinblick auf Browser vs. ffmpeg wieder einen Effekt.

(Aber irgendwie habe ich so das Gefühl, dass bei dir das Nadelöhr woanders ist und dein Browserproblem vielleicht nur durch die erhöhte CPU-Last verschlimmert aber nicht verursacht wird. Deine CPU hat zwar schon ein paar Tage auf dem Buckel, aber trotzdem fällt es mir bei so einem halbwegs modernen Quadcore schwer, mir einen ruckelnden Browser vorzustellen, nur weil nebenher was läuft. Naja, reine Spekulation.)

taskset muss man ja nacher mit der PID aufrufen - ist mit einem script natürlich blöd. autogroup beim booten - also ich wollte jetzt nicht mein ganzen System ändern.

Ich finde es schon komisch, weil ich bei einm fractal Programm auch mehrere threads angeben kann und bei 2 threads sind auch immer nur 2 CPUs ausgelastet (insgesamt ca. 50%). Insofern habe ich ffmpeg und insbesondere libx256 im Verdacht. Aber wie ich schon schrieb mit den libx256 Parametern springen die CPUs immer wieder zwischen 0 und 100% - also auch 2 CPUs max. belastet und die anderen beiden "unten". Trotzdem kratzt das den Browser (egal ob Firefox oder Chrome) wenig: das ruckelt dann bis ich ffmpeg wieder kille.

Da es quasi keinen Unterschied macht ob ich nun mit diesen Parametern die threads einschränke, lasse ich die Parameter wieder weg. Dann ist ffmpeg auch schneller und der Browser ruckelt gleich wie vorher. Komischweise ruckeln z.B. Videos im Steam client nicht, wenn ich Steam parallel starte und auf den store pages die Spielevideos abspielen lasse. Versteht kein Mensch ... 🙄

dentaku schrieb:

taskset muss man ja nacher mit der PID aufrufen - ist mit einem script natürlich blöd.

Es ging wohl eher darum, dass du mal testet, welche Kerne gut harmonieren und diese dann mittels fixer Angabe im Skript zu verwenden. Ist dann natürlich speziell auf dein Hardware-Setup abgestimmt und somit nicht gerade schön gelöst. Aber wenn der Effekt damit weg geht, wäre es doch trotzdem okay...

Achso, und die PID solltest du doch leicht mittels pidof im Skript abrufen können. Wo siehst du da das Problem?

Hab's ausprobiert

>sudo taskset -cp 1,2 10514
aktuelle Bezugsmaske für PID 10514: 6
neue Bezugsliste für PID 10514: 1,2

hat nichts gebracht: alle 4 CPUs auf 100% ...

Bei mir limitiert taskset auch Kindprozesse, wenn ich den Elternprozess mit taskset starte:

1

taskset 3 ffmpeg ...

Damit ist der Prozess und alle Kindprozesse auf Kerne 1 und 2 beschränkt.

ffmpeg hat aber keine Kindprozesse - sieht man mit "Top" : nur 1 Prozess zieht annähernd 100%: "ffmpeg".