ProLiantはデフォルト設定では本気を出してない可能性がある

我が家で動いてるサーバの中で、CPUやメモリに最も負荷がかかっている機種はDL160 Gen8というものだったりします。このサーバにはXeon E5-2640という8年ぐらい前のHexaCoreなCPUが2発搭載されてまして、リソースも相当に積まれています。

・・・・・・ここ最近どうにもCPUの処理能力が妙に遅い。一体どういうことだろうか？というこｔで、その切り分けをしていたのですが、それなりに面白いことが色々わかってきたので載せておこうと。

ProLiantのデフォルト設定は？

ProLiantのBIOS画面やiLOの画面を見ればわかるのですが、確かデフォルト値は「Dynamic PowerSaving Mode」だったと記憶しています。このモードは「負荷に応じてCPU出力を動的に変更する」と名前から推察されるわけですが、具体的にどうやってるんでしょうか、ということで。

負荷が高ければP0ステートに近くなり、アイドル状態と判断されたらP15ステートに近くなるという動作をするようで、CPU使用率が低いとクロックも同時に落とされるようです。

電力モード切替の手段

ずばり以下の通りでiLOから変更可能です。この機能に関してはStandardライセンスでも対応できる領域なので、稼働中の状態から切り替えるならこれを使ったほうが良いでしょう。

Static High-performance Modeに切り替えると、CPUステートがP0 に固定され、常にそのプロセッサの通常時最高クロックに周波数が固定されます。TurboBoostというモードを発動するのはまた別のトリガーであり、TBStateが使われるので、これについてはまた別の話ということになります。

逆にStatic Low-Power Modeは動作可能であるための最低クロックに固定します。実際に設定するとおよそ1.2GHz程度のクロック数に固定されていることを確認しています。この時、CPU本来の性能と比較するとクロックベースで半分以下の性能値に落ちるため、消費電力はかなり減りますがVMの動作に支障をきたすことが可能性としてでてくるため、注意が必要かなと思います。

電力モード切替に対するCPU応答速度の変化

今回はDL160 Gen8の電力モードを変更したときの挙動の変化が取れたので、それを載せようと思う。

グラフの中に2つのモード、その切替の境目についてまとめてあるのだけど、モード切替の影響は特にCPU待機時間（画面上では「CPU準備完了」）というパラメータに大きく反映されています。

上図は上段がUPS電力使用量（許容量を100%とした場合の割合）
下図はとあるVM（NestedVMホストの1台）のCPU待機時間です

CPU待機時間の値がモード切替を境目におよそ1/3ほどに下がっていることを確認しました。これはつまり、より短い時間でそのVMが投げた処理をCPUが完了させているということで、単純に待機時間だけ見るとおよそ3倍程度の速度で処理が完了できているということも言えるかと思います（実際は他のVMとの兼ね合いだったり投げられた処理の質によりけりだから一概には言えない）

代わりに10%ほど消費電力量が上昇しています。実は日頃の挙動から最大20%程度の消費電力上昇も確認しており、このことからおよそ50W-100W程度、CPU単体レベルだと25W-50W程度の消費電力上昇が考えられます。（我が家のUPSは500Wモデルなので）

NestedVMに対する影響

今回、たまたまこの評価をした相手がvSphereでNested環境として組み上げてるESXiサーバだったので、ついでにNested環境上で動作しているVMに対しても何かしら影響があったのだろうか？ということで調べました。

結果としてはほぼ同じ傾向で処理高速化を確認することができました。
実際にはほぼ同時のタイミングでNested VMの応答速度も向上していましたし、見かけのCPU使用率は逆に若干の低下を見せていました。要は溜め込んでるCPU処理の数が減ったということなのだろうと推察しています。

ちなみに全体としてCPU処理の数が少ない環境であれば、実はこの電力モードを変更してもあまりCPU待機時間への今日は起きません。それなりにCPUに投げる処理が多い場合にこの辺の考慮が必要なのだろうと考えられます。

電力モードの推奨事項としてはきっとこうだろうなぁ

まとめるとこんな感じですかね。

• 以下のような環境の場合は「Static High-performance Mode」を推奨する
  • データセンタに設置されていて、電力上の不安がない（剰余電力があるとか）
  • Javaベースのプログラムが動作する環境、特にJBossとか。Elasticsearchも同様。
    • これらはブート時のInitialize処理にかなりのCPUリソースを要求する。CPU処理遅延が多くなりすぎてしまうとプロセスダウンしてしまい（おそらくタイムアウト処理が発動したと予想される）、正常にアプリケーションが起動しない。
  • NSX-Tを稼働させる場合
    • とくに莫大なCPUリソースを要求するのはコントローラである。コントローラが配置されたノードに対しては省電力機能はOffにすることが望ましいと考えられる。
  • 仮想アプライアンスを稼働させる場合
    • 特にそのアプライアンスにベースとなる物理アプライアンスがある場合は注意が必要。物理アプライアンスだとASICで処理させていたものをソフトウェア処理に転嫁しているため、純粋にCPU処理能力に依存している可能性が高い。

そうしないと、実際に顧客システムを稼働させた時にシステム要件性能を満たせずに、無駄にスペックの高いサーバを調達してしまうなど若干恥ずかしい目に遭うのかもしれないなーと。

サーバの省電力機能というのは、省電力という意味ではそのとおりなんだけど、これ転じて「サーバのパーツがより長寿命になる」ということは基本ないので、その点はご注意を。

HDDだってスピンドルOn/Off繰り返すほうが故障率が高くなりますし、実は省電力稼働させるということ自体は実はサーバに負担を強いるという話にもなりますので。

また、私が構成する時はたいていHyperThreadをOffにしています。実質上のvCPU数と利用コア数に差異が生じるためです。フルにプロセッサーのパワーを要求した場合に動作不良が発生することがたまーにありますので・・そのあたりは安全策を取ることが多いです。参考までに。