はじめに
技術顧問のsatです。EPYCマシンの検証についての3回目の記事です。前回の記事はこちらです。
今回はこのマシンのビルドマシンとしての実力を見てみます。これまでの記事と異なり、手元にあったXeonのマシンとの性能比較をしています。
検証環境
サーバ(EPYCマシンと記載): Super Micro AS-1023US-TR4
- CPU: EPYC 7451 x 2 (48コア、96スレッド)
- メモリ: MEM-DR432L-HL01-ER26(32GB * 16, 合計 512GB)
- OS: Ubuntu 16.04.4
- カーネル: 4.13.0-37-generic
サーバ(Xeonマシンと記載): DELL PowerEdge R640
- CPU: Xeon Gold 5120 x 2 (28コア、56スレッド)
- メモリ: M393A4K40BB2-CTD(32GB * 16, 合計 512GB)
- OS: Container Linux by CoreOS stable (1632.3.0)
- カーネル: 4.14.19-coreos
どちらもおおよそ中位モデルのサーバ(およびCPU)です。
検証方法
ビルド負荷の一例として、Linuxカーネルのビルド速度を比較しました。このときビルドの並列度に伴ってビルド速度がどのように変わるかを確認しました。いずれのマシンもSMT*1は有効にしています。
検証結果のサマリ
検証の結果をまとめると、おおよそ次のようなことが言えます。
- 並列度が低いうちはXeonマシンのほうがビルド速度が高い
- 並列度が高くなるにつれてEPYCマシンのビルド速度がXeonマシンを追い越して、最終的にEPYCマシンのほうが1.4倍高速になる
- EPYCマシンは並列度が低い場合に性能がばらつく
検証方法
linux v4.15.7をデフォルト設定(defconfig)でビルドした場合の所要時間*2を測定しました。この際、-jオプションによって並列度を1からEPYCマシンのスレッド数である96まで変化させてデータを採取しました。
検証手順は次の通りです。
1) ソースのダウンロードと設定
$ wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.15.7.tar.xz $ tar xf linux-4.15.7.tar.xz $ cd linux-4.15.7 $ make defconfig ... $
2) ビルド(ビルドに必要なパッケージはインストール済みとします)
$ cat build.sh
#!/bin/bash
NCPU=$(grep -c processor /proc/cpuinfo)
make clean >/dev/null 2>>err.txt
for ((i=0; i<$NCPU; i++)) ; do
time make -j$((i+1)) >/dev/null 2>>err.txt
make clean >/dev/null 2>>err.txt
done >/dev/null 2>>res.txt
$ ./build.sh
検証結果
横軸に並列度を、縦軸にビルド所要時間をプロットした図を以下に示します。
一見して並列度が低い場合はXeonマシンのほうが、並列度が高い場合はEPYCマシンのほうが所要時間が短いことがわかります。では、縦軸を速度(所要時間の逆数)にしてみるとどうなるでしょうか。
並列度20あたりまでのデータを見るとスレッドあたりの速度はXeonマシンのほうが高いものの、その後は次第にEPYCのビルド速度が上がってきて、最終的にすべてのEPYCマシンのスレッド数である96並列ビルドになった際はEPYCマシンのほうが1.4倍高速であるということがわかります。
Xeonマシンのビルド速度の伸びは並列度28を超えた段階で鈍化しています。これは、並列度28以前は並列化された各処理*3がコアのリソースを占有できていたのに対して、並列度28以降はコアのリソースを2つのスレッド間で共有しなくてはいけない場合が出てくるからです。さらにその後並列度が56を超えた後はビルド速度が頭打ちになることがわかります。これは並列度56の時点でCPU資源を使い切っているため、それ以上並列度を上げてもスループットが上がらないことによります*4。
このデータにはもう一点気になることがあります。それはEPYCマシンの低並列度におけるビルド速度がXeonマシンに比べてばらつくこと、もっというと悪い方向にのみばらつくことです。この傾向はデータを何度測定しても変わりませんでした。これについては次節以降において考察しました。
EPYCマシンにおけるビルド速度ばらつき問題の調査
最新カーネルへのアップデート
本記事の検証に使ったカーネルはUbuntu16.04において使える最新カーネルであるv4.13(正確には4.13.0-37-generic)ですが、カーネルv4.15にはプロセススケジューラにEPYC対応のパッチが入っています。このパッチによって問題が解消するのではないかと推測して、より新しいUbuntuからカーネル4.15.0-13-genericを借りてきて、このカーネルにおけるデータも採取しました。
しかし推測は外れていました。カーネルをv4.15系にしても性能がばらつく問題は解消しないことがわかりました。
SMTの無効化
EPYCマシンの性能がばらつくのは並列度が低いとき、とくにEPYCマシンのコア数48を下回るときだったため、SMTが有効なとき、かつ、同時に実行中のプロセス数が少ない場合に何か問題があるのではないかと疑って、SMTを無効化した状態でデータを採取してみました。
この結果、SMTを無効化した場合はEPYCマシンにおける性能のばらつきが無くなることがわかりました。
最後に、EPYCマシンはSMTを無効化するとXeonマシンのSMT有効/無効時いずれの場合よりもビルド速度が高くなったことも見逃せません。LinuxにおけるEPYCマシンの性能にはさらなる伸びしろがあると言えるでしょう。
おわりに
EPYCマシンをビルドマシンとして見ると、スレッドあたりの性能はXeonマシンに遅れをとるものの、スレッド数が相対的に多いことを武器にして、全CPU資源を使い切ったときの性能は上回ることがわかりました。並列化された個々の処理がほとんど独立しているカーネルビルド処理ではこのような結果になりましたが、個々の処理の間で排他制御が必要な処理においても同じことが言えるのかについては別途検証が必要です。
もう一点、EPYCサーバはハイパースレッド有効時、かつ、並列度が低い場合に性能がばらつく問題があることがわかりました。このようなことになる原因にはLinuxのプロセススケジューラやプロセッサそのものなど色々なものが考えられますが、現時点では不明です。こちらについても今後の原因究明、および問題の改善についてはさらなる検証が必要でしょう。
