Document

過負荷時の分散ソフトウェアの
性能劣化を改善する
スケジューリングの提案
学籍番号 00-1966-6
日比野秀章
指導教官千葉滋助教授
1
現在の分散ソフトウェア開発
• 分散コンポーネントが多く利用される
– 例: EJB,DCOM,CORBA
コンポーネント間の通信は
Remote Method Invocation
コンポーネント
RMI
• サーバはRMIを並列処理して性能向上
– 余剰リソースを効率的に活用
– 例： I/O処理の終了待ち
2
RMIの並列処理
• 最高性能を引き出す並列度は？
– 軽いメソッド
大きいほどよい
• 処理時間の短いメソッド
– 重いメソッド
小さい方がよい
• 大量のメモリを消費、ディスクアクセスが必要なメソッド
– 多種類のメソッドが混在する場合は？
• 静的には決まらない
• 他のメソッドの処理状況に影響される
3
集中制御は難しい
• 関係する処理すべての進捗を見て、
理想的な並列度を算出・適用
– 組み合わせ爆発
– 他のJVM上の処理の進捗は
わからない
他のJVM
データ
ベース
並列度
コントローラ
2
モニタ
3
4
Method-level Queue Schedulingの提案
• メソッドごとに最大並列度を動的に独立に決定
– そのメソッドの進捗状況だけをフィードバック
– 他のメソッドの影響は進捗状況から推定する
進捗状況を
フィードバック
2
最大並列度
の制御
メソッドA
3
5
メソッドB
フィードバックによる最大並列度の決定
Mc 現在の最大並列度
スループットを測定
Mp 前回の最大並列度
Tc
十分なデータが
採取できたか？
No
Tp Mpでのスループット
最大並列度の小さな方が、ス
ループットが高いと判断
Yes
(Mc–Mp)(Tc–Tp)≧0
最大並列度
の大きな方
が、スルー
プットが高い
と判断
Mcでのスループット
No
Yes
最大並列度を⊿k 増加
最大並列度を⊿k 減少
6
ホスト単位での優先度設定
• 優先キューを作れば、
優先度別に処理順序を管理可能
優先権のないホスト
からの呼び出し
優先権のあるホスト
からの呼び出し
優先キュー
実行
– 優先度の高いものから順に処理
• 優先権を持つホストからの呼び出しについて、レスポンス時間が
短縮
7
実験
• 単一メソッドだけのフィードバック制御の効果を測定
– 重いメソッドが動いていても、軽いメソッドが圧迫されずに
動く
– 実験環境
• Java: version 1.4.2
• サーバマシン
– CPU:Intel®Xeon(TM)CPU2.4GHz×2,Memory:2GB,
OS:Linux2.4.20,NIC:100BaseTX
• クライアントマシン×15台
– CPU:Pentium733MHz,Memory:512MB,
OS:Linux2.4.19-Ovl11(VineLinux),NIC:100BaseTX
8
重いメソッドと軽いメソッドが
混在した場合の制御
• 評価方法
– 軽いメソッドを20クライアント
• 単純な数値計算
– 重いメソッドを50クライアント
• 120KB程度のXMLファイルをパースし、データ探索
を行う
– 重いメソッドは、軽いメソッド開始から10秒後に
開始
– 0.1秒間隔で処理数を測定
9
Method-level Queue Schedulingを
使用しない場合
2.0
0.0
処理数
1.0
[処理数 / 100ms]
重いメソッド
0 20 40 60 80 100
処理数
[処理数 / 100ms]
軽いメソッド
0
10
20
30
40
時間時間
[秒]
50
60
0
10 20 30 40 50 60
時間
時間[秒]
• 重いメソッドの開始により、軽いメソッドの処理が
滞っている
10
Method-level Queue Schedulingを
使用した場合
0
10
20
30
40
50
60
2.0
1.0
0.0
処理数
[処理数
/ 100ms]
重いメソッド
0 20 40 60 80 100
処理数
[処理数
/ 100ms]
軽いメソッド
0
時間
時間
[秒]
10 20 30 40 50 60
時間
時間[秒]
• 軽いメソッドの処理が滞らない
11
優先度指定による
レスポンス時間の短縮
• 評価方法
– 120KB程度のXMLファ
イルをパースし、データ
探索を行う
• 実験結果
5 10 15 20 25 30
• 対象メソッド
秒
0
– 対象メソッドを常時40ク
ライアントが呼び出す
状況下で、優先度の有
無による比較
優先ホスト通常ホスト
– 平均して約1/27に短縮
12
関連技術
• 設定ファイルに制限を明記
– 例: JBoss で使用されている
– コネクションの数を指定
• サーバで同時に処理できる数を制限
– 分散コンポーネント毎にインスタンス数を指定
• コンポーネント単位で、同時に処理できる数を制限
⇒メソッドによる負荷の違いが考慮されていない
13
まとめと今後の課題
• まとめ
– Method-level Queue Schedulingの提案と実装
• リモートメソッド単位で動的に並列処理数を制限
– 実験では
• 軽いメソッドと重いメソッドを混在させた場合でも、軽い
メソッドがある程度動くことを確認した
• 今後の課題
– 軽いメソッドが優先されることによる、重いメソッド
の性能低下を抑える
14

Download Report