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

スポンサーサイト

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

ベンチマーク2回目

実験VM(その1)

OS: WindowsServer2008R2
Disk: 40GB HDD
CPU: 1vCPU (3.5GHz)
Mem: 2GB
オフセット: パーティション開始オフセットは4096の倍数になっていることを確認




■1回目(Queue Depth: 32 / Random / 16GiB)

Random Read 4KiB (Q= 32,T= 1) : 0.999 MB/s [ 243.9 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 0.662 MB/s [ 161.6 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 1.812 MB/s [ 442.4 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 0.515 MB/s [ 125.7 IOPS]

Test : 16384 MiB [C: 24.7% (9.9/40.0 GiB)] (x5) [Interval=5 sec]

■2回目(同じ)

Random Read 4KiB (Q= 32,T= 1) : 3.503 MB/s [ 855.2 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 0.603 MB/s [ 147.2 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 4.231 MB/s [ 1033.0 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 0.602 MB/s [ 147.0 IOPS]

Test : 16384 MiB [C: 24.7% (9.9/40.0 GiB)] (x5) [Interval=5 sec]

■3回目(同じ)

Random Read 4KiB (Q= 32,T= 1) : 2.842 MB/s [ 693.8 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 0.330 MB/s [ 80.6 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 4.263 MB/s [ 1040.8 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 0.522 MB/s [ 127.4 IOPS]

Test : 16384 MiB [C: 24.7% (9.9/40.0 GiB)] (x5) [Interval=5 sec]

■4回目(50MiBにしてみた)

Random Read 4KiB (Q= 32,T= 1) : 64.789 MB/s [ 15817.6 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 1.742 MB/s [ 425.3 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 22.126 MB/s [ 5401.9 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 1.209 MB/s [ 295.2 IOPS]

Test : 50 MiB [C: 24.7% (9.9/40.0 GiB)] (x5) [Interval=5 sec]

■5回目(0x00にしてみた)

Random Read 4KiB (Q= 32,T= 1) : 107.057 MB/s [ 26137.0 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 1.736 MB/s [ 423.8 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 20.956 MB/s [ 5116.2 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 1.298 MB/s [ 316.9 IOPS]

Test : 50 MiB [C: 24.7% (9.9/40.0 GiB)] (x5) <0Fill> [Interval=5 sec]



(結果)
IOPSだけに注目:
・回数を増すごとに良い数値になる(2,3回目は誤差の範囲か)
・Test Sizeの容量が小さいほど、性能は出ている(キャッシュ利用しちゃう)
・0x00 (Zero) にするとさらに性能が出る
・パフォーマンス:CPU、Mem共に高くない、物理もモニターしたが待ちなどはなし

ClystalDiskMark FAQ

個人ブログ様

NCQ (ネイティブ・コマンド・キューイング)とは?

ディスク速度をチェック(CrystalDiskMark 3.0の操作)


IOPSに関しては実施する度に性能値が変動しすぎて、あんまりあてにならない気がする。
スループットは誤差の範囲か?

結論:よくわからない。

スポンサーサイト
  1. 2015/12/13(日) 02:43:47|
  2. VMware|
  3. トラックバック(-)|
  4. コメント:0

CPUスケジューリング

Windowsサーバリソースのデータ収集項目と判断基準の一例

パフォーマンス管理



CPUスケジューリングの基本

b1_20151211033525a77.png


b2_20151211033845aca.png



<ハイパースレッディングテクノロジー>

仮想環境でベンチマークで性能が変わる理由は掴んだが、じゃあ適切な計測の仕方ってなんなのかが不明なので、
CPU <--> メモリ <--> ディスク の状態を確認する。

箱(リソースプール)で予約していて、仮想マシンでは予約設定をしていないので
動作がいまいちよくわからない。

読み物
VMware blog


n1.png


リソースプールも複数あって、同じホストのCPUを共有している。
仮想マシンは予約されておらず、場合によっては(極論)0かもしれないし100かもしれない。
そこをどうリソースプールで予約したことで動いてくれるのかロジックが破綻。

  1. 2015/12/11(金) 03:09:14|
  2. VMware|
  3. トラックバック(-)|
  4. コメント:0

仮想 ストレージ性能

■他社クラウド事業者 IOPS制限値

※制限値です保証値ではない


→さくらのクラウド

sakura.png


→ AWS の一番いいストレージプラン

aws.png



→ ニフティクラウド(個人ブログ様)

throughput_graph_2.png


こう見ると、某IaaS事業者は何万IOPSでも出し放題、制限してないからやりたい放題
Latencyも高いときでも40msec~程で、スループットも400MiB/s以上も出ている優良事業者だなあ
ベースラインが決められてないので出せるだけ出すみたいな。どんどんかけてこどんどんかけてこ


ただ、測定するマシンのリソース容量によって大きく変わるので何とも言えない。
(AWSの通常SSDプランだと、1GB 3IOPSがベースラインっぽい)

→参考ブログ様

  1. 2015/12/08(火) 20:50:24|
  2. VMware|
  3. トラックバック(-)|
  4. コメント:0

KB 2032716

プロセッサの電力管理の設定が原因で、仮想マシンのアプリケーションのパフォーマンスが低下する場合がある

→わかりやすくまとめてあるサイト様

Cステートとは、CPUのスリープ状態のことで、C0~C7まである。
C0:CPUが動作している状態。またはすぐに動ける状態。人間で言えば「立っている状態」
C1:起きてはいるがすぐには動けない状態。人間で言えば「座っている状態」。動くには立ち上がらなければならない。
C2:座っていて部屋のドアも閉じてる状態。
C3:部屋に鍵までかけてる。
C4:電気も消してほぼ寝てる。

使ってないコアは眠ってしまい、起こしてから測れば良い性能値がでるということかな。
仕事中に眠るとかわたしかよ、全力で許す。



この現象だった。

  • 他ホストと比較して、仮想マシンのアプリケーションのパフォーマンスが低い

  • アプリケーションの実行速度が予想よりも遅い、アプリケーションを別のホストに移動すると、パフォーマンスが改善する

  • 「準備率」に示される、仮想マシンの CPU準備時間が予想よりも高くなる



  • ■内容

    ホスト上で1VMのみを乗せ(負荷はまったくない)そのVMでベンチマークを行った(顧客VMがいるホストだと影響が怖かったので。というより何も乗ってなかった(そもそもおかしいが触れない))
    →予想した性能値が出ない!CPU Ready値が異常に高い。
    →電力管理は「平衡(デフォルト)」だった。
    →パワーオン状態のVMを載せてしばらくしたら、予想した性能値が出た。


    @ベンチマークツールのせいにして何もせず終了した。


    ■2015.12.08 追記
    esxtopコマンドでESXiの状態を見てみた。
    C1でほとんどが動いていて、P値は最低ラインで動いていた。
    [詳細設定] はすべてデフォルト。
    Power.CStateResidencyCoef値が、デフォルトの5 だったのでCPUは良く眠っているっぽい。

    ■2015.12.09 追記
    ホストの設定ではなく、クラスタの設定が優先されると発覚。
    クラスタでは電力管理をオフにしているので、ホストの設定は無視されると発覚。
    それでは何故、C0ではなくC1で動いているのか、現在のところ謎。

    1. 2015/12/07(月) 20:15:54|
    2. VMware|
    3. トラックバック(-)|
    4. コメント:0

    DRS 実行間隔

    先日のCPU Readyが累計で異常値になった場合、
    何も動かないでそのまま負荷の高いホスト上でVMが稼動するのかよ、という件で
    監視は入れられるにしろ、自動的にDRS機能によって動かないのかよ、という話し。
    DRSの詳細については書籍レベルは過去記事にまとめたが、


  • DRSは、ワークロードに基づきCPUとメモリのバランスをとるので、ネットワークとストレージは考慮されない

  • ストレージはストレージDRSやストレージI/Oコントロールで調整

  • ネットワークは分散仮想スイッチの機能であるネットワークI/Oコントロールで調節



  • CPUの奪い合いが激しくなると、DRSはクラスタのリソース利用状況のバランスが崩れていることを検出し、
    内部アルゴリズムを使ってもっともバランスの取れたクラスタを作るためにはどの仮想マシンを移動すべきかを判断します。
    DRSは、すべての仮想マシンについて、各ホストへの移動をシュミレーションし、予想される結果を比較します。
    そして、もっともクラスタのバランスが得られる移動バターンを自動的に実行するか、管理者に推奨します。


    d1.png


    構成するホストの負荷(ホストの負荷 = (VMの負荷の合計) / (ホストのキャパシティ))のばらつきを標準偏差として管理し、
    この標準偏差の値が、設定されたしきい値(保守的~積極的の5段階で設定)を超えた場合、vMotionを利用して仮想マシンをほかのサーバーに移行させます


    DRSの標準負荷偏差の詳細な計算式が知りたかったのだが、
    様々なメトリックを組み合わせて標準偏差を出しているようで相当複雑な計算をしているっぽいので追求するのはやめた。

    2015.12.12 追記
    普通に参考書に標準偏差の式が載ってた。



    ■DRSの発動間隔を変更



    デフォルト:300秒(5分) ←(変更することは推奨されない、何故?)
    VirtualCenter activates the DRS algorithm after a fixed interval ( the default is five minutes ) so DRS can make recommendations based on the past performance metrics of the virtual machines in the DRS cluster. Although we recommend keeping the default valu...

    変更可能値:60秒~3600秒(1分~60分)

    ■ vpxd.cfg

    <config>
    ….
    <drm>
    <pollPeriodSec>
    300 <!--# of seconds desired between 60 and 3600 -- >
    </pollPeriodSec>
    </drm>

    </config>



    ■あと考慮できるのは、しきい値の変更か?

    3が基準、(1,2は論外)
    4,5にしたときの動作は未検証(しきい値が下がるだけ)
    (むやみに vMotionはしてほしくない)

    ■2015.12.08 追記
    監視を入れたところ、CPU Readyが5000m/s以上が恐ろしいほど頻発しているにも関わらず
    DRSでvMotionが動いた形跡がないので、3じゃ駄目っぽい?

    1. 2015/12/06(日) 01:48:38|
    2. VMware|
    3. トラックバック(-)|
    4. コメント:0
    上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。