仮想マシンへの CPU 割り当ての変化に応じた最適な並列アプリケーション実行

Presentation on theme: "仮想マシンへの CPU 割り当ての変化に応じた最適な並列アプリケーション実行"— Presentation transcript:

1 仮想マシンへの CPU 割り当ての変化に応じた最適な並列アプリケーション実行
九州工業大学情報工学部機械情報工学科 光来研究室 髙山 都旬子 グラフについてしっかり話す　BTのとことか 共有の場合 タイムスライス←こっちを省略 共有の場合を追加 物理cpuと似ているからさらっといける

2 VM 内で実行される並列アプリケーション 仮想マシン（VM）内で並列アプリケーションを動 かすことも増えてきた
物理CPU（CPUコア）をVMの仮想CPUに割り当てる 仮想CPUをアプリケーションのスレッドに割り当てる VM アプリケーション マルチコアCPUの普及で並列アプリケーション増 クラウドコンピューティングの利用でVM増 VM内で動く並列アプリケーションは図と連動して説明 物理CPU：物理プロセッサのCPUコア 仮想CPU：VMが持つ仮想的なCPU スレッド：並列処理に対応したプログラムの最小の実行単位 物理CPUと仮想CPUの説明で割り当ての説明 スレッドの説明で割り当ての説明 スレッドが物理CPUに対応付けされる　で　並列に動く VMが持つ仮想的なCPU 実行単位スレッドごとに別々の処理をする 基本的な単語の説明を図の説明前に入れる スレッド vCPU vCPU vCPU vCPU 仮想CPU 物理CPU pCPU pCPU pCPU pCPU

3 VM マイグレーション 動作中のVMが別のサーバに移動されることが ある マイグレーション先のサーバの物理CPUが足り ない場合がある
サーバのメンテナンス時や負荷分散時 マイグレーション先のサーバの物理CPUが足り ない場合がある 仮想CPUに１対１に割り当てられない 移動させることがある　から　説明 前スライドからの流れ：サーバ上でVMは動いているが できる→×可能○そういうことがある、避けられないこと 動作中のVMが別のサーバに移動させることがある VM VM マイグレーション 仮想CPU 仮想CPU 物理CPU 物理CPU サーバ1 サーバ2

4 物理 CPU の不足時の対処 (1/3) VM に割り当てる物理CPU を減らす 例：4 個→ 2 個
一つの物理CPUが複数の仮想CPUに割り当てられる VMの仮想CPU数は変わらないため 物理CPU が減った分だけ性能が低下 減らす方法があります 説明の時 左の図（見てる人から） ----- 会議メモ (16/02/22 15:39) ----- 仮想CPUの場所 中？外？ 本来なら中 VM VM 仮想CPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU 物理CPU pCPU pCPU pCPU pCPU pCPU pCPU

5 物理 CPU の不足時の対処 (2/3) VM が利用できる物理CPUの使用率を制限する 例：400% → 200%
上限を低く設定するほど性能が低下 図の例で説明 既に半分は他のVMに使われているという状況（マイグレーションの時とは違うCPUの不足の仕方） 何個の物理CPUを何％ずつ使うかはスケジューラが決定する 残り半分に色をつけて使われていることがわかるように VM VM 仮想CPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU 物理CPU 100% 100% 100% 100% 50% 50% 50% 50%

6 物理 CPU の不足時の対処 (3/3) 複数の VM 間で物理CPU を共有する 例： 1 VM で占有 → 2 VM で共有
vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU pCPU pCPU pCPU pCPU 物理CPU pCPU pCPU pCPU pCPU

7 予備実験 目的 並列アプリケーション 実験環境 物理 CPU の不足時の対処による性能低下を調査
Tascell で並列化したフィボナッチ数計算 (fib) NAS Parallel Benchmarks (BT) 実験環境 CPU: AMD Operation 6367 (16コア) × 2，メモリ: 320GB 仮想化ソフトウェア: Xen 4.4.0 VM: 仮想CPU 16個，メモリ 4GB，OS: Linux 実験環境のコア数と仮想CPU数は言う

8 物理CPU を減らした場合 割り当てる物理CPUを16個からn個に減らした どの場合も理論値より遅くなっている 理論値からの増加率
fib: 4 ～ 25%，BT: 16 ～ 78% 横軸縦軸の説明（最初のここだけ）特に横軸 物理CPU の減少分だけ低下した時の性能を理論値とした．

9 物理CPU の使用率を制限した場合 CPU使用率の上限を1600%から減らした どの場合も理論値よりも遅くなっている 理論値からの増加率
上限値が小さいほど差が大きくなる 理論値からの増加率 fib: 23 ～ 328%，BT: 157 ～ 5243% 横軸にひとこと 前スライドとの対比 さっきよりも差が大きい

10 物理CPU を共有した場合 アプリケーションを同時に実行するVMを１台からn台 に増やした 台数を増やすほど理論値より遅くなった
理論値からの増加率 fib: 12% ～ 20%，BT: 104% ～ 191% ----- 会議メモ (16/02/22 15:39) ----- ページ番号を上とか右とかに移動させる

11 理論値より性能が低下する原因 仮想CPUのスケジューリングのオーバヘッドが 原因と考えられる
システム全体の仮想CPU の数が物理CPU より多い場合、スケジューリングが必要になる 仮想CPUを切り替えるオーバヘッドがある クリックで切り替え ながらオーバヘッドが生じることを説明 VM vCPU vCPU vCPU vCPU pCPU pCPU

12 提案：pCPU-Est 物理CPUの不足時に並列アプリケーションの 実行を最適化するフレームワーク
VMが利用可能な物理CPU の数を見積もる 仮想CPUの切り替えを減らすように最適化を行う VM の仮想CPU 数の最適化 アプリケーションのスレッド数の最適化 仮想CPUスケジューラのタイムスライスの最適化（省略） タイムスライスの最適化の説明は省略するって言う

13 利用可能な物理CPU 数の見積もり 以下の数の中の最小の値とする ハイパーコールを作成してVM内から取得でき るようにした
VMに割り当てられた物理 CPU 数 CPU 使用率の上限 ÷ 100を四捨五入した値 VMの仮想CPU 数 ハイパーコールを作成してVM内から取得でき るようにした 三つの値をそれぞれの例でもいう 読まなくていい　いきなり例題で ２００％って書く pCPUのところに５０％ ----- 会議メモ (16/02/22 15:39) ----- ２個利用可能がどの条件を使ったのか書く ハイパーコールとは？ ハイパバイザを呼び出すシステムコール それとも消す 普通VM内では見られないのを取得できるようにした 強調 物理CPU数：2個→2個利用可能 CPU使用率上限÷100=2→2個利用可能 vCPU vCPU vCPU vCPU vCPU vCPU vCPU vCPU pCPU pCPU 50% 50% 50% 50%

14 VMの仮想 CPU 数の最適化 利用可能な物理 CPU 数を基に仮想CPU数を調整 仮想 CPU 数を減らすことでスケジューリングを回避
OSはホットスワップ機能を用いてCPU数を動的に変更 VM アプリケーション ホットスワップとは、コンピュータ や サーバ などのシステムの電源を入れたまま、パーツ や ケーブル、あるいは 外部機器 などを交換する操作 図を動かしながら説明 vCPU vCPU vCPU vCPU pCPU pCPU pCPU pCPU

15 アプリケーションのスレッド数の最適化 利用可能な物理 CPU 数を基にスレッド数を調整 使われる仮想 CPU 数を間接的に減らす
スレッド数はユーザが調整可能 アプリケーション実行中にスレッド数を変更するのは難しい VM アプリケーション スレッド 使われる仮想CPUと１対１になる ２つは使われないと言う ----- 会議メモ (16/02/19 13:27) ----- アプリケーションが複数動いたら単純な話ではない OSによる最適化 OS側でCPUやスレッドを最適化 ----- 会議メモ (16/02/22 15:39) ----- スレッドの表現の仕方 ４つのスレッドという vCPU vCPU vCPU vCPU pCPU pCPU pCPU pCPU

16 物理 CPU を減らした場合の最適化 スレッド数の最適化が最も性能低下を抑えられた 仮想CPU数の最適化も効果があった
高速化：1.1〜1.3倍 高速化：1.3〜2.0倍 実験の説明 物理CPU不足時の対処に対しpCPU-Estが提供する最適化手法を行うことでどの程度性能低下を抑えることができるか調査 実験環境 予備実験と同じ 何色が何かを言う 説明にあわせて どの辺りが違ったのか（仮想CPUの最適化のところ）

17 CPU 使用率を制限した場合の最適化 仮想CPU数の最適化，スレッド数の最適化ともに 効果があった 利用可能な物理CPU数と同数が最適
高速化：1.3〜4.9倍 高速化：1.2〜55倍 三枚目追加 いろいろな数でやってみて最適なものを撮ったのがこのグラフですって説明 指し棒で指しながら説明　とくに大幅に改善のところとか 同じ傾向とは？ 何％高速化したか 何倍の計算 最適化前に比べて何倍速くなったか書く（性能向上のところ） ----- 会議メモ (16/02/19 13:27) ----- 利用可能な物理CPUと同数が必ずしも最適ではない 同数ではない最適なやつをプロットしてみる 最適のものを選ぶとこうなる ほとんどは同数が最適だが一部は違うみたいなグラフ グラフ差し替え 本当に最適な値をプロット

18 物理CPU を共有した場合の最適化 他の対処を行った場合と同様の効果があった 利用可能な物理CPUと同数が最適 高速化：1.2〜1.3倍
高速化：1.3〜3.2倍 （1-最適化後/最適化前)*100

19 関連研究 VCPU-Bal [Song et al. ‘13] ロックホルダ・プリエンプション [Uhlig et al. ‘04]
VM間で物理CPUを共有する場合に最適な仮想CPU数に変更 本研究では3つの対処と3つの最適化の関係を調べた ロックホルダ・プリエンプション [Uhlig et al. ‘04] ロックを保持しているスレッドに割り当てられたCPUが他のスレッドに奪われることで処理が進まなくなる現象 提案手法はこの問題を解消もしくは緩和できる (備忘録) 仮想環境では二重スケジューリング現象がある．一つは仮想CPUのOSのスケジューリング，もう一つはハイパーバイザによる仮想CPU のスケジューリング．二重スケジューリングのギャップを解消するために，各VM の仮想CPU の数を最小化し可能な限りvCPU スケジューリングからハイパーバイザを除外する方法が考えられており，最適な仮想CPU数を見積もるのがVCPU-Bal ロック・ホルダーは、現時点でロック(データへのアクセスや更新の制御)を保有している、 または特定のロック・オブジェクトでロックを待機しているスレッドとかジョブとか プリエンプションは一時的に実行中のタスクを中断する

20 まとめ 物理 CPU の不足時の対処による並列アプリケー ションの性能への影響を調査
並列アプリケーションを最適に実行する pCPU-Est を提案 利用可能な物理CPU数を見積もる スレッド数、仮想CPU数、タイムスライスを最適化 スレッド数の最適化が効果的であることが多かった 今後の課題 状況に応じて最も効果的な最適化を自動選択 提案しました