リソース制約下における組込みソフトウェアの性能検証および最適化方法

Size: px

Start display at page:

Download "リソース制約下における組込みソフトウェアの性能検証および最適化方法"

ふじよしごちょう
7 years ago
Views:

1 リソース制約下における組込みソフトウェアの性能検証および最適化方法広島市立大学大学院情報科学研究科システム工学専攻中田明夫倉田和哉百々太市 1

2 提案技術の概要組込みシステムの開発厳しいリソース制約 (CPU, ネットワークなど ) 非機能要求 ( リアルタイム性など ) の達成開発プロセスにおける設計段階性能問題を発見することが困難実装段階で性能問題が発覚設計の手戻りが発生設計段階での性能検証手法 [1] を提案 ( 非特許 ) 性能要求を満たすだけでは不十分性能要求を満たしたうえでの, 低コスト化, 低消費電力化につながる最適化手法 [2] を提案 ( 特許出願中 ) [1] 百々太市, 中田明夫, プリエンティブスケジューリングによりリソースを共有する複数タスク動作仕様の性能検証, 組込みシステムシンポジウム (ESS2010) 論文集, pp , [2] 中田明夫, 倉田和哉, 百々太市, タイムバジェット最適化装置及び最適化方法, 特願 ( 平成 24 年 2 月 20 日出願 ) 2

3 性能検証手法の概要ソフトウェア仕様モデルから性能検証モデルへ変換および性能検証 [1] ソフトウェア仕様モデル複数タスク動作仕様単位時間に処理できるデータ数スループット要求性能検証スループット要求を満たすか否か? ( Yes/No ) 変換優先権付きストップウォッチペトリネット性能検証モデル [1] 百々太市, 中田明夫, プリエンティブスケジューリングによりリソースを共有する複数タスク動作仕様の性能検証, 組込みシステムシンポジウム (ESS2010) 論文集, pp ,

4 複数タスク動作仕様タスクグラフ周期的入力 ( スループット要求 ) タスク並列 (10) τ 2 Input(100) τ 1 par τ 3 τ 4 (20) (5) (5) タイムバジェット ( タスクの処理に使用可能な時間の割り当て ) choice (20) (30) τ 5 τ 6 endchoice 選択選択合流 τ 1 τ 2 τ 6 τ 3 τ 4 τ 5 τ 7 リソース割り当て固定優先度 (FP) resource1 1 個 τ 1 >τ 2 >τ 6 早い者勝ち (FIFO) resource2 1 個並列合流 join τ 7 output 4 (10) 出力複数タスクの順序関係や並列選択などの制御構造を有向非閉路グラフとして表現各タスクの実行に必要なリソース, 総リソース数, およびリソース競合を解決するスケジューリング方式の指定

5 優先権付きストップウォッチペトリネット : プレース : トークン : トランジション : アーク : 優先度 : ストップウォッチアーク p0 p1 p2 入力プレース t0 t1 経過時間を保持再び計測を開始計測をストップ計測開始 [3,5] [1,3] [0,6] [0,3] [1,8] [3,5] [1,3] [0,2] 時間計測開始優先度時間ペトリネット (TPN) 並列的非同期的分散的な実時間システムを表すためのモデル時間的振る舞いをモデル化可能 p4 ストップウォッチペトリネット (SwPN) 時間の計測を途中で止めたり, また再スタートさせたりすることが可能プリエンプティブスケジューリング出力プレースをモデル化可能 5 p3 優先権付きペトリネット (PrPN) トランジションの組に対して優先度を設定可能固定優先度スケジューリングをモデル化可能

6 タスクの PrSwPN への変換 τ 1 (10,30) 変換方法の特徴 : タスク内部の動作を捨象検証の効率化タスクスケジューラリソースを分離柔軟な組合せが可能スケジューラ : FIFO( 早い者勝ち ) FP( 固定優先度プリエンプティブ ) FP-np( 固定優先度ノンプリエンプティブ ) など 6

7 スループット性能検証手法 error [100,100] input p0 2 assertion システムの処理システムが p0 からトークンを得ることによって表現システム p0 に 2 個のプレースシステムの処理能力が入力に追い付いていないスループット要求を満たす error プレースにトークンが入らないスループット要求を満たさない error プレースにトークンが入る到達可能性解析に帰着 7

8 到達可能性解析検証ツール The TINA Toolbox ( 既存 ) 動作仕様指定したプレースにトークンが入る可能性があるか否か検証可能ペトリネット 8

9 評価方法性能検証の効率評価 1 リソース数を 5~20, タスク数を 30~50 まで変えた複数タスク動作仕様をランダムに 10 個ずつ生成 2 PrSwPN に変換し平均検証時間を測定検証には既存ツール The TINA Toolbox を使用検証結果はスループット制約を [ 満たす / 満たさない / 検証不能 ] で示される生成したタスクのパラメータスループット要求タイムバジェット 100[ 入力 /s] 1~10[s] 9

10 効率評価の結果タスク数に概ね比例し検証時間が増加いずれの場合も数十秒で検証完了 10

11 性能を保持したタイムバジェット最適化全体のスループット性能を満たす範囲内で, 各タスクのタイムバジェット ( タスクの処理に使用可能な時間の割り当て ) を自動的に改善正確には局所最適化 ( 初期解から最も近くこれ以上改善できない解を探索 ) タイムバジェットが長くなればより低性能のリソースで同じ性能が実現可能 11

12 タイムバジェット最適化方針レイテンシ ( 個々のデータが入力されてから出力されるまでの遅延 ) 要求に対する余裕時間を各タスクに効果的に配分することにより, 各タスクのタイムバジェットを最適化最悪レイテンシ t1 t2 t3 t4 t5 t6 余裕時間入力出力レイテンシ要求入力 t t t t t t1 t2 t3 t4 t5 t t6 出力レイテンシ要求

13 レイテンシ要求が追加された仕様タスクグラフ周期的入力 ( スループット要求 ) タスク並列 (10) τ 2 並列合流 Input(100) τ 1 par τ 3 τ 4 (20) (5) (5) タイムバジェット選択 choice (20) (30) τ 5 τ 6 (10) endchoice τ 7 選択合流 τ 1 τ 2 τ 6 τ 3 τ 4 τ 5 τ 7 リソース割り当て固定優先度 (FP) resource1 1 個 τ 1 >τ 2 >τ 6 早い者勝ち (FIFO) resource2 1 個 join output(200) 出力 ( レイテンシ要求 ) 2012/11/9 新技術説明会 13

14 タイムバジェット配分方針仮定 : 各タスクの処理時間はリソースの性能に比例リソースをより低性能にそのリソースを使用するタスク群の処理時間は同じ割合だけ増加タイムバジェット配分方針性能要求 (= スループット要求 & レイテンシ要求 ) を満たす限り同じリソースを使用するタスク群のタイムバジェットを同じ割合だけ増やす 14

15 性能検証手法の改良ソフトウェア仕様モデル複数タスク動作仕様変換スループット要求レイテンシ要求優先権付きストップウォッチペトリネット性能検証性能検証モデル性能要求を満たすか否か? ( Yes/No ) 15

16 [1,1] 最悪レイテンシ計測および 4 秒経過後 [1,1] レイテンシ性能検証 [1,1] 5 秒経過 5 秒経過後 [1,1] 入力から出力までのレイテンシ要求が 6 秒以内のシステムの例レイテンシ要求違反 [0,0] 出力 4 秒経過しなかった 3 秒経過後 4 秒経過 [1,1] レイテンシ :3 秒計測可能 6 秒経過 [1,1] 計測完了 [0,0] 計測開始システム (PrSwPN) 3 秒経過 [1,1] 1 秒経過入力 2012/11/9 2 秒経過後 1 秒経過後 2 秒経過新技術説明会 16

17 最適化の手順 1 同じリソースを共有するタスクのタイムバジェットを一定率増加させた動作仕様を各リソース毎に生成 2 各動作仕様を性能検証モデルに変換 3 生成された各モデルを性能検証 4 検証の結果性能要求を a. いずれかが満たす場合, 最悪レイテンシが最も小さいものを新しい動作仕様として選択し最初から繰り返す b. すべて満たさない場合, 最適化を終了入力の動作仕様 17

18 タスクグラフ実験 : 使用する例題 Input(100) リソース割り当て τ 1 (10, 200) τ 1 τ 2 固定優先度 (FP) r1 1 個 par τ 6 τ > 2 > τ1 τ 6 τ 2 (30, 200) τ 3 τ 4 (20, 200) (15, 200) τ 5 (20, 200) τ 3 τ 4 早い者勝ち (FIFO) r2 1 個スループット要求 :10[ 入力 /s] join (100msに1 回入力 ) レイテンシ要求 :200[ms] 以内 τ 6 (25, 200) 増加率 f :5[%] 0.5 [%] 実験環境 CPU:Intel Xeon E5607 (2.27GHz) output(200) メモリ :4.00GB OS:Windows7(x86) Professional SP1 PrSwPN 検証ツール :TINA τ 5

19 性能検証モデルへの変換プレース数 1153, トランジション数

20 実験結果 (1/2) 最適化前最適化後スループット要求を満たすか否か? Yes Yes 最悪レイテンシタスク名実行に必要なリソース最適化前のタイムバジェット最適化後のタイムバジェット τ1 r τ2 r τ3 r τ4 r τ5 r τ6 r 最適化にかかった総時間 : 約 70 秒程度 ( 検証回数 45 回最大検証時間 1.5 秒 ) r1 を共有するタスクのタイムバジェットの増加率 :145.0[%] r2 を共有するタスクのタイムバジェットの増加率 :39.5[%] 20

21 実験結果 (2/2) (20, 200) 最適化前最適化後 21

22 考察リソース r1,r2 を共有するタスクのタイムバジェットをそれぞれ 145.0%,39.5% 増加させても, 最適化前と同性能のモデルを得ることができた同じ性能要求に対して, タイムバジェットがより大きくなるため, より低性能の CPU やネットワークを使用可能 22

23 まとめ各タスクのリソース制約とタイムバジェットが指定されたマルチタスクソフトウェアの動作仕様と性能要求 ( スループット要求およびレイテンシ要求 ) が与えられたとき, 性能要求を満たす範囲で各タスクのタイムバジェットを緩和することにより局所最適化を行う手法を提案同じ性能要求に対して, タイムバジェットがより大きくなるため, より低性能の CPU やネットワークを使用可能 23

24 問い合わせ先広島市立大学社会連携センター連携推進室長 ( 特認教授 ) 社会連携コーディネーター野村啓治 TEL: FAX: [email protected] 24

memcached 方式 (No Replication) 認証情報はログインした tomcat と設定された各 memcached サーバーに認証情報を分割し振り分けて保管する memcached の方系がダウンした場合はログインしたことのあるサーバーへのアクセスでは tomcat に認証情報

memcached 方式 (No Replication) 認証情報はログインした tomcat と設定された各 memcached サーバーに認証情報を分割し振り分けて保管する memcached の方系がダウンした場合はログインしたことのあるサーバーへのアクセスでは tomcat に認証情報 IdPClusteringPerformance Shibboleth-IdP 冗長化パフォーマンス比較試験報告書 2012 年 1 月 17 日国立情報学研究所 Stateless Clustering 方式は SAML2 を想定しているため CryptoTransientID は不使用使用するとパフォーマンスが悪くなる可能性あり Terracotta による冗長化について EventingMapBasedStorageService