日本ソフトウェア科学会第 33 回大会 (2016 年度) 講演論文集

VM が利用可能な CPU 数の変化に対応した
並列アプリケーション実行の最適化
高山 都旬子

光来 健一

クラウドコンピューティングの普及により，仮想マシン（VM）内で並列アプリケーションを動かすことが増えてきた．VM は別のホストにマイグレーションされることがあるが，CPU のオーバコミットのためにマイグレーション
先のホストで物理 CPU が不足すると，VM にはマイグレーション前よりも少ない物理 CPU しか割り当てることができない．このとき，(1) 複数の VM 間で物理 CPU を共有する，(2) VM が利用できる CPU 使用率を制限する，(3) VM に割り当てる物理 CPU を減らす，という三つの対処が考えられる．しかし，我々の実験によると並列アプ
リケーションの性能は VM への CPU 割り当ての減少分以上に低下することが分かった．そこで本稿では，VM が利用可能な物理 CPU 数を見積もり，その情報を用いて並列アプリケーションの実行を最適化する pCPU-Est を提案する．pCPU-Est は仮想 CPU アフィニティを考慮して，各 VM ごとに利用可能な平均物理 CPU 数を算出する．
pCPU-Est が提供する最適化手法は，アプリケーションスレッド数の最適化と仮想 CPU 数の最適化の二つである．
物理 CPU の不足時の三つの対処に対してこれらの最適化手法を用いて実験を行ったところ，アプリケーションス
レッドの最適化が最も効果的であることが分かった．

有，(2) VM が利用できる CPU 使用率を制限，(3)1 はじめにVM の物理 CPU 割り当てを削減，という対処が考え

近年，CPU のコア数の増加により，並列アプリ

られる．しかし，我々の実験によると，物理 CPU のケーションの利用が進んでいる．並列アプリケーショ

減少分以上にアプリケーションの性能が低下すること

ンは処理をスレッドに分割して CPU の各コアに割りが分かった．

当て，同時に処理を行うことで高速化を図る．また，そこで本稿では，VM が利用可能な物理 CPU 数をクラウドコンピューティングの普及により，クラウド

見積もり，その情報を用いて並列アプリケーションのが提供する仮想マシン（VM）の中で並列アプリケー

実行を最適化する pCPU-Est を提案する．pCPU-Est

ションを動作させることも増えてきた．仮想化環境

は仮想 CPU アフィニティを考慮して，各 VM ごと

では，CPU のコア（物理 CPU）は仮想化され，複に利用可能な平均物理 CPU 数を算出する．それを基数の仮想的な CPU（仮想 CPU）として VM に提供に，pCPU-Est はアプリケーションスレッド数の最適される．物理 CPU が十分にある場合は，一つの物理化と仮想 CPU 数の最適化の二つの最適化手法を提供

CPU は一つの仮想 CPU に割り当てられる．

する．

しかし，仮想化環境では CPU のオーバサブスクリ

物理 CPU の不足時の三つの対処についてこれらプションを行うせいで物理 CPU が足りなくなる場合の最適化手法を用いて実験を行い，並列アプリケーがある．例えば，マイグレーションによって VM がションの性能への影響を調べた．その結果，最適なス他のサーバに移動され，移動先のサーバで複数の VM

レッド数は VM が利用可能な物理 CPU 数と同数でが動作する場合などである．十分な物理 CPU を確保あったが，最適な仮想 CPU 数はアプリケーションやできない時には，(1) 複数の VM 間で物理 CPU を共利用可能な物理 CPU 数に依存することが分かった．

Tokiko Takayama, Kenichi Kourai, 九 州 工 業 大 学,
Kyushu Institute of Technology.

また，スレッド数の最適化が最もアプリケーションの性能低下を抑えることができ，仮想 CPU 数の最適化ෆ䛷୪ิ䜰䝥䝸䜿䞊䝅䝵䞁䜢ື䛛䛩䛣䛸䜒ቑ䛘䛶䛝䛯| ௬᝿䝬䝅䞁

ෆ䛷ᐇ⾜䛥䜜䜛୪ิ䜰䝥䝸䜿䞊䝅䝵䞁
y ≀⌮
䜢 䛾௬᝿
䛻๭䜚ᙜ䛶䜛yෆ䛾䝇䝺䝑䝗䛿௬᝿䜢౑䛖

でもほぼ同様の効果が得られることが分かった．
以下，2 章で物理 CPU の不足時の対処について述䜰䝥䝸䜿䞊䝅䝵䞁

VM

べ，並列アプリケーションの性能低下に関する実験の

≀⌮

䝇䝺䝑䝗

䛾୙㊊᫬䛾ᑐฎ

結果を示す．3 章では pCPU-Est の提案を行い，4 章

で pCPU-Est を用いて行った実験結果について述べる．5 章で関連研究について触れ，6 章で本稿をまと

vCPU

vCPU

vCPU

vCPU

௬᝿CPU

pCPU

pCPU

pCPU

pCPU

≀⌮CPU

める．

ᑐฎᚋVM の性能低下
2 物理 CPU の不足による
2. 1 CPU 不足時の対処

図1

VM を用いた並列アプリケーション実行

仮想化環境では物理的な CPU コア（物理 CPU）
は仮想化され，仮想的な CPU（仮想 CPU）としてᑐฎ๓

VM に提供される．図 1 のように物理 CPU が十分にある場合は，1 つの物理 CPU は 1 つの仮想 CPU に

VM1

VM2

vCPU vCPU vCPU vCPU

vCPU vCPU vCPU vCPU

だけ割り当てられる．割り当て先の仮想 CPU はスケ௬᝿ジューリングによって変わる可能性があるが，仮想
CPU アフィニティを設定することによって割り当て1を固定することもできる．VM 上で並列アプリケー≀⌮

ションが動いているとき，アプリケーションのスレッ

pCPU

pCPU

pCPU

pCPU

ドはプロセススケジューラによって仮想 CPU に割り当てられて動作する．

図2

VM 間での物理 CPU の共有

仮想化環境では CPU のオーバサブスクリプションを行い，物理 CPU より多くの仮想 CPU を動作さ当てるのが最も一般的である．各仮想 CPU が利せることが多い．これはすべての仮想 CPU が物理用できる物理 CPU の割合は，VM に設定されたCPU を 100%使うとは限らないためである．一般に，重みによって決まる．例えば，2 つの VM の重サーバの CPU 使用率は 10〜20%程度と言われていみが 1:2 の場合には，33%と 67%の CPU 時間がる．しかし，並列アプリケーションは CPU を占有す

それぞれの仮想 CPU に配分される．ただし，一ることが多いため，オーバサブスクリプションを行う

部の仮想 CPU が割り当てられた物理 CPU を使と物理 CPU が不足する場合がある．特に，VM がマ

い切らない場合には，その分を他の仮想 CPU がイグレーションによって他のホストに移動されると，利用する．

ハードウェア構成や同じホスト上で動作する他の VMのワークロードが大きく変化する．そのため，マイグ• VM が利用できる CPU 使用率を制限
VM に CPU 使用率の上限を明示的に設定する

レーション前は十分な物理 CPU を使えていても，マことによっても，複数の VM 間で物理 CPU をイグレーション後には物理 CPU が不足するという事

分け合うことができる．初期状態では VM は割態が起こる可能性がある．

り当てられた物理 CPU 数× 100%の CPU を使ホストの物理 CPU が不足した場合，以下の三つの対処が考えられる．

• 複数の VM 間で物理 CPU を共有用できる．例えば，図 1 の場合では 400%が使用可能である．このときに CPU 使用率の上限を200%に設定すると，図 3 のように CPU 使用率

物理 CPU が不足する場合には，図 2 のように 1が合計で 200%を超えないように各物理 CPU をつの物理 CPU を複数の VM の仮想 CPU に割り使用する．この例ではすべての物理 CPU を使用

を持つ VM を用いた．対象とした並列アプリケーショ

VM1
vCPU

ンは，Tascell [2] を用いて並列化されたフィボナッチ

VM2

vCPU vCPU vCPU

vCPU

vCPU

数計算 (fib) と NAS Parallel Benchmarks [5] の EP

vCPU

vCPU

と BT である．
並列アプリケーションは仮想 CPU 数と同数の 16

2
50
%

50
%

40
%

60
%

25
%

75
%

40
%

60
%

スレッドで実行した．複数台の VM で物理 CPU を共有する場合，VM の台数を 1 台から 8 台まで増加させて実行時間を計測した．各 VM に設定する重み

図3は同じとし，VM 内では同じ並列アプリケーション

VM の CPU 使用率の制限を動作させた．CPU 使用率を制限する場合は，Xenの Credit スケジューラの cap の値を変更することに

VM1
௬᝿

vCPU vCPU vCPU vCPU

より CPU 使用率を 1600%から 100%まで減少させVM2

た．物理 CPU の割り当てを削減する場合には，VM

vCPU vCPU vCPU vCPUに割り当てる物理 CPU を 16 個から 1 個まで減らした．後者の二つの対処を行う場合には VM は１つだ

3

≀⌮

pCPU

pCPU

pCPU

pCPU

け動作させた．物理 CPU を 16 個占有した状態を初期状態として，物理 CPU の減少分に比例して低下することを仮定したアプリケーションの性能を理論値と

図4

VM への物理 CPU 割り当ての削減

した．
実験に用いたすべてのアプリケーションにおいて，しているが，何個の物理 CPU を何%ずつ使用す

どの対処を行った場合でも理論値より性能は低下した．

るかは仮想 CPU スケジューラによって決まる．

物理 CPU を共有した場合の結果を図 5 に示す．fib，• VM への物理 CPU 割り当てを削減

EP，BT の順に理論値と実測値の差が大きくなって

各 VM が割り当てられた物理 CPU を占有でき

おり，fib では最大で 20%，EP では 23%，BT ではるように，仮想 CPU アフィニティを利用して仮191%の性能低下が起きた．物理 CPU を多くの VM

想 CPU 数より少ない物理 CPU を割り当てるこ

で共有するほど性能低下が大きくなった．図 6 に示すともできる．この場合，VM の仮想 CPU 数は変

ように，CPU 使用率を制限した場合ではその傾向がわらないため，1 つの物理 CPU が 1 つの VM のより顕著に現れた．fib では 23%から 328%，EP で複数の仮想 CPU に割り当てられる．図 1 の状態

は 30%から 373%，BT では 157%から 4138%の性能から割り当てる物理 CPU を半分に減らすと，図低下が起きた．一方，物理 CPU の割り当てを削減

4 のように 2 つの仮想 CPU で 1 つの物理 CPU

した場合の結果は図 7 のようになり，fib では最大でを分け合うことになる．

25%，EP では 27%，BT では 78%と性能低下が小さ
かった．

2. 2 並列アプリケーションの性能低下

理論値よりも性能が低下する原因として，仮想 CPU

物理 CPU が不足した場合の三つの対処を行ったと

スケジューリングのオーバヘッドが考えられる．物

きに，VM 上で動く並列アプリケーションの性能の理 CPU が不足するとスケジューリングによって仮変化について調査した．この実験には，2 基の AMD

想 CPU を切り替える必要があるため，物理 CPU の

Opteron 6376（16 コア），320GB のメモリを搭載

減少分以上の性能低下が起きた可能性がある．また，したマシンを用いた．仮想化ソフトウェアには Xen

ロックホルダ・プリエンプション [8] や vCPU スタッ

4.4.0 を使用し，16 個の仮想 CPU と 4GB のメモリ

キング [7] の発生も原因の一つと考えられる．ロック

୙㊊

୙㊊

60

୙㊊

80

ᐇ

50

್

180

70

⌮ㄽ್

ᐇ

್

160

⌮ㄽ್

30
20

ᐇ⾜᫬㛫[s]ᐇ⾜᫬㛫[s]ᐇ⾜᫬㛫[s]

40

50
40
30

80
60
40
20

0

1

2

4

0

1

8

2

(a) fib

್

800

1

図5

⌮ㄽ್

400

200

100

୙㊊

୙㊊

200
180
160
140
120
100
80
60
40
20
0
1600

ᐇ

್

800

(a) fib

⌮ㄽ್

400

200

100

್

60
40

ᐇ

್

140

60
40

0

0
4

2

1

್

⌮ㄽ್

80
60
40
20
0

16

8

4

≀⌮CPUᩘ

2

1(b) EP
図7

ᐇ100≀⌮CPUᩘ

(a) fib

100

120

80

20

200

୙㊊

⌮ㄽ್

100

20

400

⌮ㄽ್

(c) BTᐇ⾜᫬㛫[s]ᐇ⾜᫬㛫[s]ᐇ⾜᫬㛫[s]

80

್

160

140

⌮ㄽ್

8

800

୙㊊
CPU 使用率の制限時の性能低下

120

16

ᐇ

CPU౑⏝⋡

160

120

ᐇ

200
180
160
140
120
100
80
60
40
20
0
1600

(b) EP
図68(c) BTCPU౑⏝⋡

୙㊊

4

物理 CPU 共有時の性能低下CPU౑⏝⋡

100

2

VMྎᩘ

ᐇ⾜᫬㛫[s]ᐇ8(b) EPᐇ⾜᫬㛫[s]ᐇ⾜᫬㛫[s]

200
180
160
140
120
100
80
60
40
20
0
1600

4

VMྎᩘ

VMྎᩘ

୙㊊

⌮ㄽ್

100

10

0

್

120

20

10

ᐇ

140

60

16

8

4

2

1

≀⌮CPUᩘ

(c) BT

物理 CPU の割り当て削減時の性能低下

ホルダ・プリエンプションは，ロックを保持している仮想 CPU に割り当てられた物理 CPU が他の仮

3 pCPU-Est

想 CPU に奪われることで処理が遅延する現象であ

本稿では，VM が利用可能な物理 CPU 数を見積もる．vCPU スタッキングは，ロックを待っている仮想

り，それに基づいて仮想 CPU の切り替えを減らすた

CPU がロックを保持している仮想 CPU よりも先にめの最適化を行う pCPU-Est を提案する．これによ

物理 CPU を割り当てられたために処理が進められなり，仮想 CPU の切り替えオーバヘッドの削減やロッい現象である．

クホルダ・プリエンプションや vCPU スタッキング

のアフィニティが設定されている場合，各物理 CPU
0

1

3

2

௬᝿CPU

4

はそれらの仮想 CPU すべてにつながれる．図 8(a)は，物理 CPU 0, 1 から仮想 CPU 0, 1，および，物

0

1

2

3

理 CPU 1, 2, 3 から仮想 CPU 2, 3, 4 へのアフィニ≀⌮CPU

ティが設定された場合の例である．

(a)
0

1

3

2

4

pCPU-Est のグラフ分割アルゴリズムは以下のよう
0

1

3

2

4

になる．まず，グラフ上でつながっている仮想 CPU
数が最小の物理 CPU を選択し，その物理 CPU とそ

0

1

0

3

2

1

1

3

2

3

(c)

(b)
0

2

4

0

1

3

2

4

れからつながっている仮想 CPU からなるグループを作成する．これは，グループの 物理 CPU 数 （物理仮想 CPU 数
CPU の割合）がなるべく大きくなるようにするためである．次に，そのグループからつながっている物理

0

1

2

3

0

(d)
図8

1

2

3

(e)

物理 CPU と仮想 CPU の分割例

CPU のうち，つながっている仮想 CPU 数が最小の物理 CPU を選択し，その物理 CPU とそれからつながっている仮想 CPU を含めたより大きなグループを作成する．このグループの物理 CPU の割合が元のグの解消もしくは緩和が可能となり，物理 CPU の不足

ループより大きいか等しければ新しいグループを採時に並列アプリケーションを最適に実行することがで用する．これを繰り返してグループをできるだけ大きる．

きくする．新しいグループの物理 CPU の割合のほうが小さくなった場合は，グループからその外側につな

3. 1 物理 CPU 数の見積もりがっている辺を削除する．

pCPU-Est は物理 CPU と仮想 CPU をいくつかのグラフの残りの部分に対してこの作業を繰り返し，グループに分け，各仮想 CPU が利用できる物理 CPU

グラフ全体がいくつかのグループに分割されたら，作の割合を算出する．そして，それを基に各 VM が利用成されたグループをできるだけマージする．これは，できる平均物理 CPU 数を見積もる．このとき，同じ局所的にグループ分けを行うだけでは正しいグラフ

グループ内のすべての仮想 CPU は，VM に設定され分割ができないためである．まず，削除された辺でつた重みが同じであれば同じ割合の物理 CPU を利用す

ながれていた２つのグループを選び，その辺の仮想ることができるようにする．物理 CPU の割り当てに

CPU 側をグループ 1，物理 CPU 側をグループ 2 と制約がなければ物理 CPU と仮想 CPU は全体で１つする．グループ 2 の物理 CPU の割合のほうが大きいのグループを形成するが，仮想 CPU アフィニティがか等しければ，２つのグループをマージする．これを設定されていると複数のグループに分かれる可能性が削除された辺でつながれていたすべてのグループにある．明示的にアフィニティを設定していない場合でついて繰り返す．

も，仮想化システムによって暗黙のうちに NUMA ア
フィニティが設定されることもある．NUMA アフィ

このアルゴリズムを図 8 に適用すると以下のようになる．

ニティは NUMA を考慮した CPU 割り当てである．

(1) 図 8(a) では，物理 CPU 0 につながっている

pCPU-Est は図 8 のような物理 CPU と仮想 CPU

仮想 CPU 数が最小の 2 であるので，これらでグのグラフを用いてグループを作成する．物理 CPU とループを作成する．

仮想 CPU は頂点となり，物理 CPU が仮想 CPU に(2) （1）で作成されたグループの物理 CPU の割合

割り当てられている場合にそれらは辺でつながれる．

が 21 であるのに対し，物理 CPU 1 と仮想 CPU

いくつかの物理 CPU からいくつかの仮想 CPU へ

2, 3, 4 を追加した新しいグループの物理 CPU の並列アプリケーションが用いるスレッド数を VM

割合は 25 と小さくとなるため，物理 CPU 1 と仮が利用可能な物理 CPU 数に応じて調整すること

想 CPU 0, 1 をつなぐ辺を削除する．

(3) 残った物理 CPU の中で，つながっている仮想で，並列度をなるべく高く保ちつつ，仮想 CPU

CPU 数が最小であるのは物理 CPU 1 なので，の切り替えを減らす．スレッド数はユーザが容易

物理 CPU 1 と仮想 CPU 2, 3, 4 で図 8(b) のよに調整することが出来るが，実行中に変更可能かうなグループを作成する．このグループからつどうかはアプリケーション依存である．

• VM の仮想 CPU 数の最適化

ながっている物理 CPU の中で，つながっている
仮想 CPU 数が最小であるのは物理 CPU 2 なのVM の持つ仮想 CPU 数を利用可能な物理 CPUで，図 8(c) のように物理 CPU 2 を追加したグ数に応じて調整にすることで仮想 CPU の切り替ループを作成する．元のグループの物理 CPU のえを減らす．VM の仮想 CPU 数を変更すること

割合が 13 であるのに対し，新しいグループは 23

はシステムの管理者にのみ可能であるため，VMと大きくなるため，新しいグループを採用する．

のユーザがこの最適化を行うことはできない．

(4) 同様にして，図 8(d) のように物理 CPU 3 を追加したグループを作成すると物理 CPU の割合

4 実験

が 1 となるので，新しいグループを採用する．

pCPU-Est の最適化手法における最適なスレッド(5) 作成された２つのグループは削除された辺（図数および最適な仮想 CPU 数を調査し，CPU が不足

8(e) の点線）でつながれていたため，マージできした場合の三つの対処について最適化の効果を調べないかをチェックする．最初に作成されたグルー

た．この実験では，2.2 節と同じ実験環境，同じ並列

プは削除された辺の仮想 CPU 側であるためグアプリケーションを用いた．

ループ 1 となり，次に作成されたグループは物理 CPU 側であるためグループ 2 となる．グルー

4. 1 最適なアプリケーションスレッド数

プ 1 の物理 CPU の割合は 12 であるのに対し，グ

VM が利用できる物理 CPU 数と最適なアプリケー

ループ 2 は 1 と大きいため，これらのグループ

ションスレッド数の関係を調べる実験を行った．物をマージして１つのグループを作成する．

理 CPU の不足時の三つの対処を行った際に様々なス

グラフ分割アルゴリズムによって作成されたグルー

レッド数でアプリケーションを実行し，その実行時間

プ内で，VM に設定された重みに応じて物理 CPU をを計測した．実測値の理論値からの減少率を図 9 に仮想 CPU に均等に分配する．図 8 の場合，VM の示す．物理 CPU を共有した場合には fib，BT とも重みが同じであれば各仮想 CPU に分配される物理

16が最適なスレッド数となった．CPUVM の台数
使用率を制限した時には CPU 使用率に対応する物理

CPU の割合は 54 となる．次に，それぞれの VM のに持つ仮想 CPU に分配される物理 CPU をすべて足しCPU 数と同じスレッド数にしたときが最適になり，合わせる．この値が小数となる場合は小数点以下を切物理 CPU を削減した場合にも物理 CPU 数と同数のり上げ，その値を VM が利用可能な物理 CPU 数とスレッド数が最適という結果になった．このことかする．例えば，図 8 の仮想 CPU 0, 1 が 1 つの VM

ら，最適なスレッド数は VM が利用可能な物理 CPUに属する場合，その VM が利用可能な物理 CPU 数

数と同数であることが分かった．

は 2 となる．

また，最適なスレッド数で実行したアプリケーショ
ン性能は理論値よりもよくなることが分かった。さ3. 2 最適化手法

らに、VM に割り当てる物理 CPU 数が少なくなるほ

pCPU-Est が提供する並列アプリケーションの実

ど、理論値からの減少率が大きくなることも分かっ

行最適化は以下の二つである．

• アプリケーションのスレッド数の最適化た。これはスレッド数を減らすことによるスケジュー
リングオーバヘッドの削減が原因ではないかと考えら

50

1

2

4

8

4

Ͳ20

8

Ͳ40

16

Ͳ60
Ͳ80
Ͳ100

40

2

0
1

Ͳ50

2

4

8

Ͳ100

8

Ͳ150

16

Ͳ200
Ͳ250
Ͳ300

20

1600

Ͳ20

1200

800

600

400

200

100

4

Ͳ40

6

Ͳ60

8

Ͳ80

12
16

(c) CPU 使用率制限時 (BT)

40

1
10

2
0
16

12

8

6

4

2

1

4

Ͳ20

6

Ͳ30

8

Ͳ40

12

Ͳ50

16

Ͳ60

⌮ㄽ್䛛䜙䛾ῶᑡ⋡[%]⌮ㄽ್䛛䜙䛾ῶᑡ⋡[%]20CPU౑⏝⋡(b) 物理 CPU 共有時 (BT)(a) 物理 CPU 共有時 (fib)

1
20

Ͳ100

VMྎᩘ

VMྎᩘ

Ͳ10

4

⌮ㄽ್䛛䜙䛾ῶᑡ⋡[%]20⌮ㄽ್䛛䜙䛾ῶᑡ⋡[%]⌮ㄽ್䛛䜙䛾ῶᑡ⋡[%]

20

1
20

2
0
Ͳ20

16

12

8

6

4

2

1

6

Ͳ60

8

Ͳ80

12

Ͳ100

16

≀⌮CPUᩘ

≀⌮CPUᩘ

(d) 物理 CPU 削減時 (fib)(e) 物理 CPU 削減時 (BT)

図9

4

Ͳ40

スレッド数がアプリケーション性能に及ぼす影響れる。

実験では，最適なスレッド数と最適な仮想 CPU 数は
物理 CPU 数と同数と仮定した．

4. 2 最適な仮想 CPU 数

物理 CPU を共有した場合，最も性能低下を抑える

VM が利用可能な物理 CPU 数と最適な仮想 CPUことができたのは図 11 よりスレッド数の最適化であ数の関係を調べる実験を行った．図 10 にアプリケー

ることが分かる．仮想 CPU の最適化でもほぼ同等のションの実行時間の理論値からの減少率を示す．fib

効果が見られたが，VM が 8 台の時の fib や 2 台の時では三つの対処のいずれの場合でも，VM が利用での BT でスレッド数の最適化ほどの性能改善は見らきる物理 CPU 数と同数の仮想 CPU 数が最適となっれなかった．ただし，いずれの場合でも最適化を行わた．一方，BT ではある程度その傾向が見られたもの

ない場合よりは大幅に性能を改善できた．

の，異なる仮想 CPU 数が最適となる場合もあった．

CPU 使用率を制限した場合でも，図 12 のように

例えば，CPU 使用率を 1200%〜600%に制限した場

スレッド数の最適化と仮想 CPU の最適化は似た傾向合の最適な仮想 CPU 数は対応する 12〜6 ではなく，を示した．CPU 使用率を 100%に制限した時の fib とそれよりも大きな値になった．また，物理 CPU 数を1200%〜600%に制限した時の BT ではスレッド数の12〜6 に削減した場合も，最適な仮想 CPU 数はそれ最適化のほうが効果があった．後者については，VM

よりも大きな値となった．この結果より，最適な仮想が利用可能な物理 CPU 数が最適な仮想 CPU 数ではCPU 数は VM が利用可能な物理 CPU 数と同数であないためだと考えられる．

ることが多いが，アプリケーションや物理 CPU の不足量にも依存することが分かった．

物理 CPU を削減した場合でも，図 13 に示すように同様の結果になった．物理 CPU 数が 12 の場合のBT では，仮想 CPU 数の最適化を行わなかった場合
4. 3 最適化の効果

より性能が悪化した．これも仮想 CPU 数が最適に

pCPU-Est の二つの最適化手法を物理 CPU の不足

なっていないためと考えられる．

時の三つの対処に適用し，どちらがアプリケーションの性能をより改善することができるかを調べた．この

50

1

2

4

8

Ͳ20

4
8

Ͳ40

16

Ͳ60
Ͳ80
Ͳ100

50

2

0
1

Ͳ50

2

4

8

4

Ͳ100

8

Ͳ150

16

Ͳ200
Ͳ250
Ͳ300

VMྎᩘ

VMྎᩘ

(a) 物理 CPU 共有時 (fib)(b) 物理 CPU 共有時 (BT)

2
16

12

8

6

4

2

1

Ͳ20

4

Ͳ40

6
8

Ͳ60

12

Ͳ80

16
Ͳ100

≀⌮CPUᩘ

(d) 物理 CPU 削減時 (fib)40᭱㐺䛺䝇䝺䝑䝗ᩘ30᭱㐺䛺௬᝿CPUᩘᐇ⾜᫬㛫[s]

20
10
0
1

2

4

80
70
60
50
40
30
20
10
0

8

8

Ͳ150

12
16

Ͳ200

1
2
16

12

8

6

4

2

1

4

Ͳ50

6
Ͳ100

8

Ͳ150

12
16

Ͳ200

≀⌮CPUᩘ

180
160
140
120
100
80
60
40
20
0

᭱㐺໬䛺䛧
᭱㐺䛺䝇䝺䝑䝗ᩘ᭱㐺䛺௬᝿CPUᩘ

1
2

4

2

8

物理 CPU の共有時の最適化

200

200

᭱㐺໬䛺䛧
ᐇ⾜᫬㛫[s]᭱㐺䛺䝇䝺䝑䝗ᩘ᭱㐺䛺௬᝿CPUᩘ

50

100

᭱㐺໬䛺䛧

150

᭱㐺䛺䝇䝺䝑䝗ᩘ100᭱㐺䛺௬᝿CPUᩘ

50
0
1600

800

400
200
CPU౑⏝⋡

100(b) EP(a) fib
図 128(c) BT(b) EP

150

4
VMྎᩘ

VMྎᩘ

᭱㐺໬䛺䛧
ᐇ⾜᫬㛫[s]40᭱㐺䛺௬᝿CPUᩘ

1

200

400
200
CPU౑⏝⋡

100(c) CPU 使用率制限時 (BT)᭱㐺䛺䝇䝺䝑䝗ᩘ

図 11

800

200

6

᭱㐺໬䛺䛧

(a) fib

0
1600

400

(e) 物理 CPU 削減時 (BT)

VMྎᩘ

100

600

Ͳ100

ᐇ⾜᫬㛫[s]ᐇ⾜᫬㛫[s]

᭱㐺໬䛺䛧

800

仮想 CPU 数がアプリケーション性能に及ぼす影響

60
50

1200

Ͳ50

ᐇ⾜᫬㛫[s]

図 10

2
1600

50

1

0

1

0

CPU౑⏝⋡⌮ㄽ್䛛䜙䛾ῶᑡ⋡[%]⌮ㄽ್䛛䜙䛾ቑຍ⋡[%]20⌮ㄽ್䛛䜙䛾ῶᑡ⋡[%]20⌮ㄽ್䛛䜙䛾ῶᑡ⋡[%]⌮ㄽ್䛛䜙䛾ῶᑡ⋡[%]

20

150

᭱㐺䛺䝇䝺䝑䝗ᩘ100᭱㐺䛺௬᝿CPUᩘ

50
0
1600

800

400
200
CPU౑⏝⋡

100(c) BTCPU 使用率の制限時の最適化

ぐ．これらの問題は，仮想 CPU とアプリケーション

5 関連研究スレッドの二重のスケジューリングによって生じるたVCPU-Bal [6] は VM の仮想 CPU 数を動的に増減

め，VCPU-Bal では仮想 CPU が物理 CPU に一対一させる vCPU バルーニングを用いて，ロックホルダ・に割り当てられるように VM の仮想 CPU 数を調整

プリエンプション [8] や vCPU スタッキング [7] を防する．各 VM の仮想 CPU 数は VM の重みに応じて᭱㐺䛺䝇䝺䝑䝗ᩘ

80

᭱㐺໬䛺䛧

60

᭱㐺䛺௬᝿CPUᩘᐇ⾜᫬㛫[s]ᐇ⾜᫬㛫[s]

100

40
20
0
16

8

4
≀⌮CPUᩘ

2

1

160
140
120
100
80
60
40
20
0

᭱㐺໬䛺䛧

ᐇ⾜᫬㛫[s]120᭱㐺䛺䝇䝺䝑䝗ᩘ᭱㐺䛺௬᝿CPUᩘ16(a) fib

8

4≀⌮CPUᩘ

2᭱㐺໬䛺䛧᭱㐺䛺䝇䝺䝑䝗ᩘ᭱㐺䛺௬᝿CPUᩘ

16

8

4≀⌮CPUᩘ

21(c) BT(b) EP
図 13

1

160
140
120
100
80
60
40
20
0

物理 CPU の削減時の最適化決定される．一方，pCPU-Est では仮想 CPU アフィ

きない．

ニティも考慮して VM の仮想 CPU 数を決定するこVM の I/O 性能を改善するために，仮想 CPU スとができる．FlexCore [4] は VCPU-Bal を実装した

ケジューリングのタイムスライスを調整する手法がシステムであり，仮想 CPU の競合の検出，VM とハ

提案されている．vSlicer [11] は I/O レイテンシに敏

イパーバイザ間の効率のよい通信，仮想 CPU のホッ

感な VM に短いタイムスライスを割り当てることにトプラグを実現している．

より，仮想 CPU をより速く横取りできるようにして

vScale [1] は VM の仮想 CPU 数を VCPU-Bal より

I/O 処理を高速化する．しかし，VM は一般に様々もきめ細かく調整することを可能にしている．VCPU-

な処理を行うため，VM 単位での割り当ては難しい．

Bal と同様に，vScale も基本的には VM の重みに応この問題を解決するために，MDPVS [3] は実行時のじて仮想 CPU 数を決定する．しかし，VM が割り

I/O 情報を用いて，I/O 処理にだけ短いタイムスライ

当てられた物理 CPU を使い切らなかった場合，そのスを割り当てた物理 CPU を用いる．vTurbo [10] でVM の仮想 CPU 数を減らし，他の VM の仮想 CPU

は各 VM に I/O 処理専用の仮想 CPU を用意し，そ数を増やす．このような頻繁な仮想 CPU 数の変更のタイムスライスだけを短くする．しかし，タイムスを可能にするために，vScale では OS が迅速に仮想ライスを短くするとスケジューリングのオーバヘッド

CPU を再構成する機構を提供する．VCPU-Bal やが増加する．

vScale では複数の VM が物理 CPU を共有することを想定しているが，pCPU-Est では CPU 使用率を制限したり物理 CPU 割り当てを削減したりすることも想定している．

6 まとめ
本稿では，物理 CPU が不足した時に並列アプリ
ケーションの実行を最適化する pCPU-Est を提案しコスケジューリング [9] は VM のすべての仮想 CPU

た．仮想化環境では物理 CPU が不足した場合に様々を同時に物理 CPU にスケジュールすることにより，な対処が行われるが，物理 CPU の減少分以上に並列

ロックホルダ・プリエンプションなどの問題を解決す

アプリケーションの性能が低下することが分かった．

る．しかし，必要な数の物理 CPU がそろうまでスケ

pCPU-Est は仮想 CPU アフィニティを考慮して VM

ジューリングを行うことができず，高い優先度を持っが利用可能な物理 CPU 数を見積もり，アプリケー

た仮想 CPU が低い優先度の仮想 CPU より後にスケ

ションスレッド数の最適化および仮想 CPU 数の最適ジュールされる可能性もある．バランススケジューリ

化の二つの最適化手法を提供する．実験の結果，スング [7] は VM の各仮想 CPU を異なる物理 CPU に

レッド数の最適化が最も効果的であることが分かった．

スケジュールすることで vCPU スタッキングを防ぐ

今後の課題は，pCPU-Est を用いて見積もった物

が、ロックホルダ・プリエンプションを防ぐことはで

理 CPU 数でどこまで最適な実行が可能かを調べるこ

とである．別の最適化手法として，Linux の cgroupsを用いてアプリケーションが利用する CPU を制限する手法についても検討する予定である．また，1 つの VM の仮想 CPU 数を最適化するとシステム全体に影響が及ぶため，それに合わせて他の VM の仮想

CPU 数も最適化できるようにする必要がある．さらに，VM の仮想 CPU 数を減らしても利用可能な物理

CPU 数が減らないようにするスケジューリング機構も必要である．

参 考 文 献[ 1 ] Cheng, L., Rao, J., and Lau, F.: vScale: Automatic and Eﬃcient Processor Scaling for SMP
Virtual Machines, Proceedings of the 11th European
Conference on Computer Systems, 2016.
[ 2 ] Hiraishi, T., Yasugi, M., Umatani, S., andYuasa, T.: Backtracking-based Load Balancing,
Proceedings of the 14th Symposium on Principles and Practice of Parallel Programming, 2009,
pp. 55–64.
[ 3 ] Hu, Y., Long, X., Zhang, J., He, J., and Xia, L.:
I/O Scheduling Model of Virtual Machine Based on
Multi-core Dynamic Partitioning, Proceedings of the
19th ACM International Symposium on High Performance Distributed Computing, 2010, pp. 142–
154.
[ 4 ] Miao, T. and Chen, H.: FlexCore: Dynamic

Virtual Machine Scheduling Using VCPU Ballooning, Tsinghua Science and Technology, Vol. 20,
No. 1(2015), pp. 7–16.
[ 5 ] NASA Advanced Supercomputing Division:
NAS Parallel Benchmarks,
http://www.nas.nasa.gov/publications/npb.html.
[ 6 ] Song, X., Shi, J., Chen, H., and Zang, B.: Schedule Processes, not VCPUs, Proceedings of the 4th
Asia-Pacific Workshop on Systems, 2013.
[ 7 ] Sukwong, O. and Kim, H. S.: Is Co-scheduling
Too Expensive for SMP VMs?, Proceedings of European Conference on Computer Systems, 20011,
pp. 257–272.
[ 8 ] Uhlig, V., LeVasseur, J., Skoglund, E., and Dannowski, U.: Towards Scalable Multiprocessor Virtual Machines., Proceedings of the 3rd Virtual Machine Research and Technology Symposium, 2004,
pp. 43–56.
[ 9 ] VMware, Inc.: Co-scheduling SMP VMs in
VMware ESX Server, 2008.
[10] Xu, C., Gamage, S., Lu, H., Kompella, R.,
and Xu, D.: vTurbo: Accelerating Virtual Machine I/O Processing Using Designated Turbo-sliced
Core, Proceedings of the 2013 USENIX Annual
Technical Conference, 2013, pp. 243–254.
[11] Xu, C., Gamage, S., Rao, P. N., Kangarlou, A., Kompella, R. R., and Xu, D.: vSlicer: Latency-aware Virtual Machine Scheduling
via Diﬀerentiated-frequency CPU Slicing, Proceedings of the 21st International Symposium on HighPerformance Parallel and Distributed Computing,2012, pp. 3–14.