Webサーバの製作3

サーバ用CPU EPYC 9965 192-Core 384-Threadを入手したので、Webサーバの構築を行なった。

Webサーバの仕様

前回のEPYCサーバの場合と微妙に異なるが、ほとんど同じ仕様になっている。 IPMIが使えることは前サーバと同じ。IPMIを通じてLAN経由で他のPCから操作ができる。

今回の製作はかなり苦労した。 アメリカとの貿易摩擦も関係しているのか、周辺機器を入手することがいささか困難であり、結構時間を要した。

マザーボードは以前SuperMicro社のH12SSL-CTを使ったが、その後継のH13SSL-NTはCPU500W非対応であったため使用不可であった。 CPU500W対応のマザーボードはなかなか無く、Gigabyte社のMZ33-CP1が対応していることをやっと見つけることができた。 しかし、テスト環境で空冷ファンを取り付けてみたが、起動不可であった。 TDP500W非対応だと安全装置が働くとのこと。（㈱ニューエックス技術部からメールで親切に教えてもらった。感謝！） 水冷に切り替えると動作したので、直接本番環境を構築することになった。

水冷ファンを直接マザーボードのCPU_FANに取り付けていたが、初期設定で不安定であった。 低速から最高速へとうるさい音とともに繰り返した。そのため、マザーボードの損傷が心配になり、ファンコントローラを別途追加した。 ファンコントローラは電力を直接PSU（電源装置）からもらい、CPU_FANで制御する仕組みになっている。 残念ながら、それでも不安定性は変わらなかった。 幸いなことに、BMC（IPMI）でファンプロファイルを設定することで解決した。 Gigabyteマザーボードの欠点がネット上で指摘されていて、低い出力設定があると誤動作するらしい。 設定を高めにすることで無事解決した。 ファンコントローラの追加に意味があったのか不明だが、安全対策は講じておいた方がいいに決まっている。

本マザーボードはHDDのRAID構成を基本としているようだ。 ソフトウェアRAIDかハードウェアRAIDなのか不明だが、HDDは非常に遅く、CPUは非常に速い。 HDDのRAIDプログラムのシステムに対する負荷が非常に小さいことは、自明の理である。 CPUの高性能化による高速化の恩恵で、HDDのソフトRAIDの利用は非常に合理的である。 わざわざ高価なハードRAID装置を購入する必要はないだろう。 と言いつつ、HDDが損壊した場合の復旧作業はどうなのかいささか心配だ。 従来のハードRAID装置にあるような復旧のノウハウがあるのだるうか？ 今回はHDDのRAIDは行なっていないので、RAID用のケーブルが束になってマザーボードの一角に鎮座している。

SSDはすべてキオクシアの製品にしたかったが、一部Crucial社の製品になった。 空冷ファン付きが購入の決め手になった。 しかし、ファンの部分が立体的に空間を占めるので、マザーボードに追加設置できるPCIE拡張スロットが少なくなった。 4つのPCIE拡張スロットの内、2つはメモリと競合し、1つはこのSSDと競合しているので、使えるのは１つのみになった。（図1参考）

図1. EPYC 9965 server 組み立て

SSDをハードRAIDにしたのは、SSDそのものが非常に高速であるため、CPUと競合すると思われるためである。 HDDのハードRAIDはあまり意味がないと述べたが、SSDを使用する場合は別で、CPUに対してHDDよりはるかに負荷が大きくなるのでハードRAIDにする意味があるだろう。 このことは、OSのマルチタスクもしくはマルチプロセスと関係が深く、IO待機問題と深い関わりがある。 通常、OSはマルチタスクで動作し、IO待機時、CPUは他のタスクもしくはプロセスに自動的に切り替わる。 Java Webfluxでも、効率のよいマルチスレッドを実現している。極力CPUに負荷を掛けない対策が重要となる。

どこの国の製品？
AMD、Micron、Seagate、Crucialはアメリカ、Gigabyte、SilverStoneは台湾である。 KIOXIAはかつて東芝メモリであった日本企業である。非常に高性能であり、信頼している。 HighPointはネット検索でアメリカにあるように見えるが、中国企業のようにも見える。 つまり、よくわからない。 現在、同等の性能を持つ台湾製のRAID装置に差し替える予定。 バックドアの議論があり、極力その危険性を排除したいと考えている。 アメリカ企業や台湾企業も中国に工場を持つ企業が存在する。 あまり気にしすぎてもきりがない。信頼できるメーカならば問題ないだろう。

その他の設定

BMCやBIOSのアップデートを行い、メモリチェックを行なった。 ECCメモリはしっかりと認識されていることを確認した。 時代の流れは速いもので、ECCも改良され、前回は72ビットECCであったが、今回は80ビットになっている。 8ビットから16ビットECC時代の幕開けだ。これにより、修正不可メモリエラーが大幅に減った。 OSはUbuntu24.04Serverをインストールした。 なお、ECCのエラー検知はいまだに出来ていない。 有料版のMemtestを購入し、メモリテストができると期待したが、 Epycシリーズは小売で購入できる商品にはプロテクトが掛かっているとのこと。 まあ、簡単にメモリエラーが発生できてしまうと、ハッカーの餌食になるだけかもしれない。

数値計算による速度比較

Ryzen7、Epyc7443p、Epyc9965の処理速度比較を行なった。 膨大な量の計算を分割してマルチスレッドで計算することで比較した。 計算はすべてJavaWebfluxで行った。 WebfluxはCPUのスレッド数に対応したスレッドプールで処理を実行するようになっている。 しかし、ここでのスレッド数はJavaプログラム上のスレッド数であり、実際のOS上のスレッド数と異なることに注意が必要である。
以前にWebfluxの解説で台形公式による積分計算を紹介した。 (Spring WebFlux事始め)
計算テストはこのプログラムを使用している。

図2. 数値計算時間スレッド数依存性の比較

図２は両対数プロットなのでいくらかわかりにくいが、 横軸はスレッド数であり、スレッド数１はCPUコア内の１つのスレッドのみを使って処理を行い、 スレッド数が増加すると共存する他のコアのスレッドを利用するようになり、 計算時間は激減するようになる。 Ryzen7は8コア16スレッドなので、ちょうど16スレッドのとき計算速度はピークになっているのがわかる。 それ以降スレッド数を増やしても計算時間はほとんど変わらない。

Epyc7443pは24コア48スレッドなので、48スレッド付近で最高性能に到達している。 Ryzen7と同様にそれ以上スレッド数を増やしても性能はあまり変わらない。 計算の都合上、2のべき乗でスレッド数を指定しているため、48は32と64のプロットの間に位置する。 分割数を2のべき乗にするのは、割り算問題が大いに関係している。 2のべき乗で割ると誤差は完全に排除できるメリットがある。

Epyc9965は192コア384スレッドである。 スレッド数384付近が性能のピークだと思ったが、様相は全く異なっている。 スレッド数2048付近またはスレッド数1万以上でピーク性能になっている。 また、スレッド数64付近と4096付近で山があり、性能にばらつきがある。 Java Webfluxの相性の問題か、それとも他の要因かわからない。 Epyc9965の性能を発揮するにはスレッド数を増やせば増やすほどよいことは確かなようである。

どのタイプのCPUも1コア1スレッドの計算能力は多少変動はあるがそれほど大きく異なっていない。 スレッド数が多ければ多いほどマルチスレッド対応のプログラムはその性能が飛躍的に増大している。 Epyc9965は多くの処理を同時実行するシステムにおいてその性能を発揮する優れたCPUであることを保証している。

なお、Ryzen7のみWindows OSであり、その他はUbuntu24.04 OSで実行した。 そのため実行環境が大きく異なっているため、公平な比較にはなっていないことに注意してもらいたい。 Ryzen7のWindowsではキャッシュの状況が大きく計算時間を変動させていた。 時には数倍の処理時間を表示した。 そのため、Windowsを再起動した直後の環境で測定テストを行なった。 その他のCPUはそのような注意をしていないので、多少大きめに数値が出た可能性がある。

作成日:2025.08.26 更新日:2025.09.17