Ryzenすごいね、速いよ、安いよ、省エネだよ、ってことで とびついた人も多いと思う。実際速い。消耗品費でこれはめちゃありがたい。 だが、 Ryzen SEGV Battle で知られるように、初期ロットに厄介なバグがある。 RMA 申請して無事良品を手に入れることも可能ではあるようだが、 はっきりいって申請にかかる時間と手間を考慮すると二の足を踏む。 実際、うちでも購入したツクモに連絡し、その後 アスクに飛ばされたが、アスクは2通目以降の連絡を よこさずだんまりを決め込んでいる。まあ AMD が悪いのだが。
そして、バグ発生の条件を揃えて再現をはかる時間があったら、 だましだまし「そこそこ」安定して使える環境を調える時間に使う方が いいんじゃないかと考えるのも悪くないと考え、その一案を示す。
ここにある記述は、たんに確率的・経験則的にそうだというだけで、 技術的裏付けがない。そもそもこのCPUバグが、 低い発生確率の元に起こるものなので、 回避できているかの検証も極めて難しい。よって、
を念頭に置いて、利用できるところだけ利用するようにしてほしい。
先に結論を。バグありRyzenをそこそこ安定した環境で、 なるべく高性能を発揮させるための案:
上記の判断に至った流れを示す。文を短くするため、 以下において以下の略語を用いる。
カーネルのmakeを -j論理CPU数 の並列度で無限に回す負荷の掛け方を示す。
pkgsrc.tar.xz (ファイル数183429)の「展開、ディレクトリツリーコピー、 削除しながら gtar -Ipixz」という負荷を論理CPU数だけ並列に動かす、 という負荷の掛け方を示す。
それぞれ FreeBSD/amd64 11.1、NetBSD 7.1.1、 LinuxMint 18.3mate(64bit) でテストした。
導入したものは以下のとおり。
CPU | Ryzen 5 1600 (6C12T 3.2GHz) |
---|---|
M/B | ASUS PRIME X370-PRO |
Memory | 64GiB(CT2K16G4DFD824A×4枚) |
HDD | Toshiba MD05ACA600とMD04ACA600のミックス3台 |
大きな流れを示す。
【負荷 K】でgccのSEGVがすぐ出た。NetBSDもLinuxも同様。 NetBSD が出やすかった。
【負荷 K】で全く同様にSEGV。
ここで別のRyzen7サーバ発注中の業者より、 「ディスクに高負荷を掛けるとハングアップする」という情報を聞く。
【負荷 K】と【負荷 D】を同時に掛けると Load average 160 くらいまでずんずん上がるが、1時間もしないうちにハングアップ。 シリアルコンソールからのBREAKも効かず、 接続ディスプレイは「NO SIGNAL」。ハングアップはSEGVよりはるかに たちが悪く全く実用にならないことに呆然。
やはりハングアップ。固まり方も上記と同じ(ホスト OSごとハングアップした)。
◎正常に使えた。だがしかし、6CPUで使えても面白くない。
ここで先の業者より、 「FreeBSDはいったん棚上げしてWindowsでテストする」と連絡をもらう。
ならこちらでもやってみるか。
FreeBSDを入れた6TB×3をいったん外し、別HDDにWindows10導入。
Windowsで高負荷を掛ける方法が全く分からないので VirtualBox
を入れてゲストFreeBSDで【負荷 K】と【負荷 D】を掛けた。
→ VirtualBoxでのゲストFreeBSDのVirtualBoxプロセスが異常終了
VirtualBoxが弱いのかな…?
ゲストFreeBSDで【負荷 K】と【負荷 D】を掛けた。
→ 落ちない
だが、【負荷 D】によるディスクIOが遅すぎてプロセスが進まず、
Load average も0.5すら行かないポンコツ状態。VMware
のほうが VirtualBox よりディスクが速いって言ってる人は
何計ってるの? 並列度の低いIOなんだろな(あとで RDM
なら速いと分かる)。
落ちはしないがこの性能の悪さは使いたくない。Windows 上だから遅いのかな。ならHypervisorでオーバーヘッドのない状態にしよう。
さらに別の2TB-HDDを差して VMware vSphere Hypervisor(ESXi) 6.5 を入れ、ローカルのデータストアにFreeBSDを入れ【負荷 K】と 【負荷 D】を掛けた。結果は意外にも
VMware Playerのときと変わんない! 遅い! 遅い! 何これ。Load average 0.5 じゃん。落ちないけどさ。 これじゃ使い物にならん。
ただ、この時点で「ハングアップするよりはマシ」 と ESXi をチューンしながら使おうと判断し、無償ライセンスを登録して ゲストの最大コア制限 8vCPU でなんとか頑張ってみると決めた。
6TB×3のHDDをRDM(Raw Device Mapping)登録して、 ダイレクトにFreeBSD(RAID-Z)ディスクを読ませた。 その上で【負荷 K】と【負荷 D】を同時に回した。
◎落ちない! なおかつ、IOのひっかかりもない。 8コアだが Load average 65 くらいまではじゃんじゃん上がる。 そのときの ESXi ホストの応答もあまり落ちない。
この状態では4コア遊んでるので、ESXi で4コア割り当ての NetBSD ゲストを動かしてその中で【負荷 K】を掛けたがそれでも平気。
以上の実験から、いくつかの推測が生まれた。
さて、そうすると「1つのゲストに登載HDDを委ねて8vCPUで動かす」という ことになるが、RAID5(RAID-Z)なんかをやりたかったらどうするの? たとえば4台積んでたとして、1つはvSphereに、3つはゲストのRAID用にする。 3つののHDDを1つのゲストに渡しちゃったら、せっかくの VMware で1つしかOS動かせないやん。 じゃあ3台のHDDを同じパーティション分けにして RDM登録をパーティションごとに行なうとか……面倒臭すぎる!
さらにいえば、残り4vCPU分遊んじゃうのはもったいない。
ということで、以下のような考え方で資源を割り振る作戦とした。
(Guest)(Guest) (Guest) |
(Guest)(Guest) (Guest) |
VirtualBox | VirtualBox |
FreeBSD [HDD][HDD][HDD] |
FreeBSD [DataStore] |
ESXi | |
Ryzen5 Hardware |
ゲスト1/ゲスト2で動かす仮想化機構としてbhyveを試したのだが、 IOがスタックしてしまってうまく行かなかった(原因未調査)ので とりあえず nested vm は VirtualBox とした。