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