FC2ブログ
基盤系インフラSE 4年目 技術備忘録 派遣社員(特定派遣)

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告|
  3. トラックバック(-)|
  4. コメント(-)

vCPU数 CPU Ready の関係

→ CPU Ready とは
-----
丸コピ

仮想環境における CPU パフォーマンス管理のポイントとして、CPU 使用率に加えて、CPU の競合状態を把握する事が挙げられます。一般的に CPU を起因とするパフォーマンスの劣化が発生した場合は、以下の要因が考えられます。

ホストのサイジングの問題:仮想マシンに割り当てている CPU の個数が適当ではない。
ゲストのサイジングの問題:仮想マシンに割り当てている vCPU の個数が適当ではない。
以上の問題を判断するために必要な CPU パフォーマンスの指標(参考値)は下記のとおりです。

  • ホスト:75% 程度

  • ゲスト:システムに依存

  • 上記及び、ゲストにおける Steal の発生率、CPU Ready 等でシステムのパフォーマンスを確認します。

    Steal とは

    ゲスト OS がリソース要求を行ったにも関わらず CPU リソースを割当ててもらえなかった時間の割合を示します。Steal が 0% でない場合は、CPU 制限が適用されているか、他のゲストと「取り合い」をして競合状態になっている可能性があり、ホストを増設する等の対応が求めれます。Steal は、top コマンド or vmstat コマンドで確認できます。

    CPU Ready とは

    物理 CPU コアが別の仮想マシンで使用される事で、競合が発生し、ESXi でスケジューリングされた vCPU が待ちを強いられている時間を示します。steal との違いは、具体的な時間[ms]を確認できる点です。vCPU あたり 20秒の累積の参考値として 2000-4000ms 程度が指標となるようです。CPU Ready の確認は、vSphere のパフォーマンスチャートから確認します。



    第1回 vSphereにおける仮想基盤の健全性を今一度チェック!



    VCP問題集に以下のような問題があった

    Q.ESXホストで複数の仮想マシンを実行しており、CPUの使用率が100%に近いものはまったくありません。
    このような状況であるにもかかわらず、すべての仮想マシンが多くの CPU Ready(準備完了)を累積していることに気付きました。
    この根底にある原因として適せつなものはどれですか。

    A.仮想マシンでI/Oの制約がある
    B.仮想マシンでネットワークの制約がある
    C.仮想マシンのNX/XDをマスクしている
    D.仮想マシンは複数の仮想CPUを持っているが、1つのCPUのサイクルの一部分しかアクティブにしようしていない
    E.VMotionによる移行がいくつか発生している


    ・・・

    Answer. D
    複数のvCPUを使用して仮想マシンを構築する場合、割り当てられたvCPUを仮想マシンがアクティブにしようしているかどうかに関係なく、
    すべてのvCPUは物理CPU上に同時にスケジューリングされる必要があります。この場合、複数のvCPUがアイドル状態であることが原因で、
    ESXホストの物理CPUの使用率が予想よりも低いことがわかります。
    この状態のとき以外は実行可能な仮想マシンは、CPU Readyを蓄積し、物理CPUが利用できるようになるのを待機します。


    各仮想マシンの仮想CPU数が多くなると、スケジューリングが難しくなり、CPUの割り当て待ちが増加します。各仮想マシンに割り当てる仮想CPU数を必要最低限の値にすることで、不要にCPUの割り当てを待たされることが少なくなり、物理CPUリソースを有効活用できます。


    仮想 SMP + vCPU オーバーコミットと性能劣化のリスク
    http://www.vfrank.org/2011/01/31/cpu-ready-1000-ms-equals-5/


    10% = 2000ms~4000ms CPU Readyが発生していると高いと判断できるみたい。(パフォーマンスチャートは20秒累積値)

    cpuready2.png

    cpuready.png

    →この本


    1n.png

    2n.png

    3n.png

    4n.png

    5n.png

    6n.png

    7n.png

    8n.png

    9n.png

    10n.png

    11n.png


    キャプるの疲れた 
    vCenter Alarmで監視はすぐ入れれるよう
    あとは、VMware-vSphere5-kaisetsu-2.pdf でぐぐr



    考察:
    ホストのCPU競合が起きて、CPU Ready(15000ms~20000ms = 15秒~20秒)が発生したのは事実。
    共用サービスである以上、仕方ない。

    たまたま物理CPUが足りなくて待ちになったとはいえ、顧客は適切なベンチマーク測定ができない。
    まして過去に測定したときよりも落ちていたら、性能劣化を疑うのは自然。

    顧客が一時的にベンチマークツールなどの高負荷のかかる処理を行うことが良いのか悪いのかは別として、
    CPU Readyが発生した場合、適切な動作(vMotionとか?)をすることができるか(DRS?)?
    そもそもそういう適切な動作ができないんだったらベンチマークして性能を測定する意味ある?
    待ちが発生しているのにいつまでもその物理ホストに乗っかってたら意味ない。

    どのぐらい CPU Readyが発生したらパフォーマンスに影響がでるのか調査したほうがよさそう。

    現在の問題点?
  • CPU Ready が 15000m/s 以上も出てしまったのが、ベンチマークのせいだという根拠がない(恐らくそうだとしても)

  • CPU Ready が 大量(どのぐらい?)に発生しているのに、何の動作もしない現状(動くのかもしれないが根拠もない)

  • DRS の動きを理解していない(5分毎に起動するとか計算値とかしきい値とか)

  • CPU Ready または、esxtopの CPUsteal を監視していない



  • ■2015.12.04 追記
    再度確認してみたら CPU Ready値 75,000 m/s ~80,000 m/s だった。

    ■2015.12.08 追記
    監視を入れたところ、CPU Readyが5000以上が恐ろしいほど頻発しているようなので、
    CPUのオーバーコミットが頻繁に起こっている or リソースのCPU制限値よりオーバーっぽい。

    ■2015.12.09 追記
    CPU Readyについて、個人的に当たりがついた。
    発生しているのが深夜帯ということで確信に近づいている。
    あとはそのときのホストに乗ってるVMの全体コア数の確認と、VMのワークロードのデマンドを見れば確信になる。

    1. 2015/12/02(水) 23:32:44|
    2. VMware|
    3. トラックバック(-)|
    4. コメント:0

    コメント

    コメントの投稿

    管理者にだけ表示を許可する

    上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。