【Linux】ffmpegによるエンコード処理でマルチスレッドとCPUアフィニティの実験

環境

HW

• Core i7 5820K(6core/12threads)

SW

• CentOS6(kernel 3.18.25)
• ffmpeg 2.8.2

背景

ホスト上で全力でエンコードを回しているとVM（特にWindows）がスローダウンしたり、X Window上での作業に影響が出るため

• どの程度スレッドを割り振れば良いのか
• エンコード処理を動かすコアを指定できないか

を検証しようと思いました。

ちなみにffmpegのビルドについては以前書いてます。

Linuxで動画をエンコードするためにffmpegを導入する - HYLOGICS

所感

うーん、ffmpegにthreads設定するとtasksetでCPUアフィニティを設定しても無視するような挙動をしてる気が

— kirine (@kirinetter) July 25, 2016

%cpu8でffmpeg動かしながら%cpu0〜7でVM稼働中。問題なく動画も再生できる感じ。 pic.twitter.com/zsNwQRxHv6

— kirine (@kirinetter) July 25, 2016

よし、CPUアフィニティさえ設定すればエンコードしながらGTAプレイしても特に問題発生せず

— kirine (@kirinetter) July 25, 2016

"-threads 1"だとCPUアフィニティが有効になるが、それ以外（マルチスレッド有効）の設定にするとダメっぽい

— kirine (@kirinetter) July 25, 2016

性能テスト（07m56s mpeg2 -> x264）
threads 1 16m15.969s
threads 4 5m23.953s
threads指定なし 3m48.561s

— kirine (@kirinetter) July 25, 2016

スレッド１だとx0.5, スレッド４だとx1.5, スレッド指定なしでx2というところかな。スレッド指定なしはもう少し早くても良さげだけどディスクI/Oにボトルネックがあるんだろうか

— kirine (@kirinetter) July 25, 2016

ボトルネックがどこかにあるんだろうけど、以前RAMディスク上でエンコード回しても早くならなかったんだよなあ

— kirine (@kirinetter) July 25, 2016

再試験してみたけどやっぱり60fpsくらいしか出ないな

— kirine (@kirinetter) July 25, 2016

結論

1. スレッド数を増やしたりディスクI／Oを改善してもエンコード速度はそんなに速くならない(スレッド数1 -> 4で速度は1.5倍、1 -> 12で速度は2倍)
2. CPUアフィニティの設定はプロセス稼働後にtasksetで動的に指定する（プロセス起動時には指定する方法はわからなかった）
3. シングルスレッドであればCPUアフィニティを指定してVMとは別のコア/スレッドでプロセスを動かすことが可能
4. マルチスレッドだとCPUアフィニティの設定を無視して動くため、VM（特にWindows）への影響がある

ということを踏まえて、恐らく性能と負荷のバランス的には4〜12の間でスレッドを指定すれば良いと判断。とりあえずホスト上で8スレッドで回してみたところ、この程度であればエンコード速度も殆ど劣化せず、VMへの負荷も少ないため動画を観たりしても余裕な感じなので暫くこのまま運用しようと思います。

Intel CPU Core i7 5820K 3.30GHz 15Mキャッシュ LGA2011-3 Haswell E BX80648I75820K【BOX】