|
0
|
1 \chapter{分散デバッグ機能と評価}
|
|
3
|
2 ４章にてJava言語によるLindaサーバーとLinda APIの実装を行った事を報告した。
|
|
|
3 Java言語による実装を得た事により、Federated Lindaへの機能拡張を比較的容易に行う事が可能となった。
|
|
4
|
4
|
|
|
5 Federated LindaによるCompact Routingの実験においては、ルーティングテーブルの構築を例に、
|
|
|
6 分散環境でのスケーラビリティをもった実装を確認しようとしたが、現状のLindaの実装では個々のノードが
|
|
|
7 どのような通信状態をもってスケーラビリティを達成するのか明確に確認することが困難なばかりか、
|
|
|
8 meshトポロジにおける実験においてはどのような通信状態によってノード全体のスケーラビリティが低下
|
|
|
9 しているのかを確認するすべが存在しなかった。これを解決する為には、Federated Lindaの通信を阻害せずに
|
|
|
10 大域的な情報でデバッグが行えるインターフェースが必要である。
|
|
|
11
|
|
3
|
12 よって本章では分散環境におけるデバッグの難しさと分散デバッグに必要な機能について説明し、
|
|
4
|
13 そのうちから通信状態のスケーラビリティを確認するという点において、
|
|
|
14 Federated Lindaでの分散開発環境におけるデバッグ機能の追加を行う。
|
|
|
15 本論文でFederated Lindaに追加する分散デバッグ機能のアプローチは、
|
|
|
16 4章で必要性を述べた通信状態のデバッグをJava版Linda サーバーへの拡張を行う事で実現するものである。
|
|
0
|
17
|
|
3
|
18 %分散アルゴリズムのデバッグの難しさ
|
|
|
19 %逐次アルゴリズムのデバッグ手法 ーー二分法
|
|
|
20 %gdbの全ノードへの手法による限界、ログをprintfするのではダメ
|
|
|
21 %デバッグする対象 デッドロック、ライブロック、スケーラビリティ、通信の集中、大量のパケット（ACK）
|
|
|
22 %個々の部品が正しく動いていても全体として正しく動かない場合がある。二分法は無力、
|
|
|
23 %スナップショットがあれば二分法が使える、量はかなり多い、デッドロックの検出も可能、循環した依存性の検出
|
|
|
24 %分散デバッガでおかしなぶぶんを見つけて、入力タプルと出力タプルを特定
|
|
|
25 %そうすれば逐次型でデバッグできる
|
|
5
|
26 %重要なのはスナップショット、便利
|
|
3
|
27 %分散デバッグアルゴリズム自体がスケールしなければいけない、一カ所にデータを集めるのはいけない
|
|
5
|
28 %通信の集中は統計で見れる-> 今回はコレ
|
|
3
|
29 %ビジュアライゼーション、意味不明なprintfを視覚的に
|
|
|
30
|
|
|
31 \section{分散環境におけるデバッグ}
|
|
4
|
32 分散環境における分散プログラムのデバッグは逐次型プログラムに比べて困難である。
|
|
|
33 それは、一般的に用いられるgdbやIDE(統合開発環境)のデバッガが逐次プログラムをデバッグする為に
|
|
|
34 機能を提供するのに対して、分散プログラムには、一般的なデバッガではデバッグが困難な特徴が
|
|
|
35 存在する為である。
|
|
0
|
36
|
|
4
|
37 ここでは一般的なデバッガを用いた二分法によるデバッグ手法と、分散プログラム開発での
|
|
|
38 シーケンシャルなデバッグ手法では解決困難な問題点について説明する。
|
|
|
39 \newpage
|
|
3
|
40 \subsection{二分法による逐次アルゴリズムのデバッグ}
|
|
4
|
41 一般的なgdbやIDEのデバッガ等を用いた二分法での逐次アルゴリズムのデバッグは、
|
|
|
42 プログラムの単体試験や結合試験工程では大変有効な手法である。
|
|
3
|
43
|
|
4
|
44 特にこの手法を用いるのにおいて適している状況は、プログラムにおけるバグの存在が既知であり、
|
|
|
45 そのバグを生じさせることが確実であるという場合である。以下に二分法の基本的な方法を示す。
|
|
|
46
|
|
|
47 \begin{center}
|
|
|
48 \begin{itembox}[l]{二分法によるデバッグ}
|
|
|
49 {\small
|
|
|
50 \begin{center}
|
|
|
51 \begin{verbatim}
|
|
|
52 [条件定義]
|
|
|
53 ・バグは既知であり、再現性があること
|
|
|
54 ・バグはプログラムの状態（大域変数と局所変数の値）から判断できること
|
|
|
55
|
|
|
56 [二分法]
|
|
|
57 1. プログラムの初期実行をα = s0とする
|
|
|
58 2. バグが発生している時点の実行ステートメントを β = sN とする
|
|
|
59 3. N' = N/2 とし sN'のプログラムの状態にバグがあるかどうかを調べる
|
|
|
60 4. バグがあるかないかによってα = sN'またはβ = sN'とする
|
|
|
61
|
|
|
62 5. 上記を繰り返す事により α +1 = β となる
|
|
|
63 6. これにより、バグが存在する時点の実行ステートメントとプログラムの状態を得る
|
|
|
64 \end{verbatim}
|
|
|
65 \end{center}
|
|
|
66 }
|
|
|
67 \end{itembox}
|
|
|
68 \end{center}
|
|
|
69
|
|
|
70 上記の手法は簡単ながらも非常に強力なデバッグ手法であり、半ば自動化された作業によってバグの特定を
|
|
|
71 可能とする。
|
|
|
72 しかし、分散プログラムの開発工程においては、上記の手法では解決困難な状況が存在する。
|
|
|
73 次は、そのような状況についてFeederated Lindaの通信状態のデバッグを例に説明する。
|
|
3
|
74 \subsection{シーケンシャルなデバッグ手法の問題点}
|
|
4
|
75 二分法を用いたシーケンシャルなデバッグ手法を前述したが、分散アルゴリズムの開発においては、
|
|
|
76 二分法では解決できない状況が存在する。
|
|
|
77
|
|
|
78 その状況とは、分散環境の各ノード、つまり全体を構成する個々の部品が正しく動いていても、全体としては
|
|
|
79 正しく動かないという状況が存在する事を指す。
|
|
|
80
|
|
|
81 ここで、Federated Lindaの通信状態を例にシーケンシャルなデバッグ（つまり単体の部品のデバッグ）が
|
|
|
82 有効な場合と、単体のシーケンシャルなデバッグでは全体の動作の正しさをデバッグできない例をそれぞれ
|
|
|
83 示す。
|
|
|
84
|
|
|
85 \newpage
|
|
|
86 \subsubsection{単体のデバッグが有効な例}
|
|
|
87 図ref{seqdeb}に示すのはFederated Lindaにおける通信にて、単体のプロセスに対する逐次デバッグが
|
|
|
88 有効な場合の通信状態である。
|
|
|
89 この通信の場合においては１つのInputに対して1つのOutputを持つプロセスのデバッグを行う事で、
|
|
|
90 全体の動作に関係する通信の流れをとらえることが可能であるからである。
|
|
|
91 \begin{figure}[htbp]
|
|
|
92 \begin{center}
|
|
|
93 \includegraphics[width=8cm]{fig/pdf/seqdeb.pdf}
|
|
|
94 \caption{単体のデバッグが有効なFederated Lindaの通信}
|
|
|
95 \label{seqdeb}
|
|
|
96 \end{center}
|
|
|
97 \end{figure}
|
|
|
98
|
|
|
99 \vspace{-1cm}
|
|
|
100 \subsubsection{単体のデバッグでは全体の正しさをデバッグできない例}
|
|
|
101 続いて図\ref{nonseqdeb}に示すのはFederated Lindaにおける通信で、単体のデバッグでは全体の正しさを
|
|
|
102 デバッグできない例である。なぜ全体の動作に対する正しさをデバッグできないかというと、
|
|
|
103 図に示すデバッガを接続したプロセスが１つのInputに対して1つのOutputを正しく出力する事がデバッグ
|
|
|
104 できても、デバッグを行ったプロセスとは関係しない通信の流れが存在する為に、プロセスの全体の通信に対
|
|
|
105 する依存性をデバッグできない為である。
|
|
|
106
|
|
|
107 \begin{figure}[htbp]
|
|
|
108 \begin{center}
|
|
|
109 \includegraphics[width=8cm]{fig/pdf/nonseqdeb.pdf}
|
|
|
110 \caption{単体ではデバッグが困難なFederated Lindaの通信}
|
|
|
111 \label{nonseqdeb}
|
|
|
112 \end{center}
|
|
|
113 \end{figure}
|
|
|
114
|
|
|
115 このような個々のプロセスをデバッグしただけでは全体の正しさが分からない場合、gdbやIDEのデバッガとい
|
|
|
116 った逐次デバッガを全ノードに対して接続することが考えられるが、このような手法は全体を構成するノード
|
|
|
117 が大規模化した場合においてその手間やリソースの集中におけるスケーラビリティの低下や、一度に大量の
|
|
|
118 デバッグ情報が取り扱われる為に、その中から求めている情報を取捨選択することの困難さ等が問題となる
|
|
|
119 ので、全ての分散環境におけるデバッグの手法としては正しくない。
|
|
|
120
|
|
|
121 また、デバッガによるプロセスの停止によってネットワークの遅延や送信データの喪失が起これば、
|
|
|
122 全体の通信の同期に必要とされるデータが揃わないまま同期を取ることになる。
|
|
|
123 そうなると本当の意味での同期が取られていないということになり、バグ再現の為の条件が一定の通信状態
|
|
|
124 を要求する場合において問題がある。
|
|
3
|
125
|
|
6
|
126 \section{分散デバッグ機能の検討}
|
|
4
|
127 これまで二分法による逐次アルゴリズムのデバッグと分散環境におけるデバッグの問題点を述べた。
|
|
|
128 ここでは、Federated Lindaに必要なデバッグ機能を提案するために、分散アルゴリズムにおいてデバッグ
|
|
|
129 すべき要素を挙げ、それらをデバッグ可能な機能としてスナップショットを用いた分散デバッグを説明する。
|
|
|
130 %また、Federated Lindaを用いる事でスケーラビリティを持った分散デバッグ機能を実現することについても
|
|
|
131 %述べる。
|
|
|
132 \subsection{分散アルゴリズムにおいてデバッグすべき対象}
|
|
|
133 %デバッグする対象 デッドロック、ライブロック、スケーラビリティ、通信の集中、大量のパケット（ACK）
|
|
|
134 分散アルゴリズムにおいてデバッグすべき対象には以下のものがある。
|
|
|
135 {\large
|
|
|
136 \begin{center}
|
|
|
137 \begin{verbatim}
|
|
|
138 ・デッドロック
|
|
|
139 ・ライブロック
|
|
|
140 ・スケーラビリティ
|
|
|
141 ・通信の集中
|
|
|
142 ・大量のパケットの送信
|
|
|
143 \end{verbatim}
|
|
|
144 \end{center}
|
|
|
145 }
|
|
|
146 \subsubsection{デッドロック}
|
|
|
147 デッドロックとは、あるプロセスが永遠にブロックされている状態を示す。そのプロセスはある条件が
|
|
|
148 真になる（例えばある資源がreadできるようになる）のを待っているが、その条件を真にするはずの別の
|
|
|
149 プロセスがその条件を執行しないが為に、どちらも何もできなくなるのである。
|
|
3
|
150
|
|
4
|
151 Federated Lindaにおけるプロセスの通信は、porlingベースの通信ループを持ち、
|
|
|
152 通信のパケットは一旦キューに溜め、ある一定のタイミングでまとめて通信を行うことから明確な「待ち」
|
|
|
153 というプロセス状態は発生しないが、ユーザープログラムによる「待ち」処理記述の可能性からデッド
|
|
|
154 ロックの検出は必要である。
|
|
|
155
|
|
|
156 \subsubsection{ライブロック}
|
|
|
157 ライブロックはデッドロックと異なり、プロセスは実行状態にあるものの、適用されるべきプログラム状態
|
|
|
158 の変化が何も成し遂げられない状態を指す。
|
|
|
159
|
|
|
160 例としてFederated Lindaにおけるプロセス間通信で説明すると、あるルーティングテーブルの構築に対
|
|
|
161 して２つのプロセスがそれぞれルーティング情報を保持しており、それぞれが相手のプロセスの
|
|
|
162 保持するルーティング情報を必要としている場合に、両者が相手のルーティング情報を得る為に自身
|
|
|
163 の保持する情報を解放した場合が考えられる。当然ながら、この両方のプロセスは相手の情報を期待して
|
|
|
164 いる為に実質的に何も達成できないという状態になる。
|
|
|
165
|
|
|
166 \subsubsection{スケーラビリティ}
|
|
|
167 スケーラビリティとは、サービスを受けるユーザー数が小規模から大規模に変化しても同じ様に同等
|
|
|
168 の能力を発揮できるという性能基準のことである。
|
|
|
169
|
|
|
170 Federated Lindaにおけるスケーラビリティの確認は、前提としてはノード数の増加に対する
|
|
|
171 プログラムの実行速度やサービス提供能力のパフォーマンスを、実際のアプリケーションを用いて
|
|
|
172 行う事があるが、現在の様に開発途中の段階では、部分的なプログラムの動作を見てその領域における
|
|
|
173 スケーラビリティを検証することが必要である。その点においてデバッグインターフェースによる
|
|
|
174 スケーラビリティの測定を可能とする事は重要であると考えられる。
|
|
|
175
|
|
|
176 \subsubsection{通信の集中}
|
|
|
177 分散プログラムの開発段階においては、通信の集中によるバグの発生は常に起こりうる事態である。
|
|
|
178 事実、Federated LindaによるCompact Routingの実装では、ある１つのノードに対してルーティング情報が
|
|
|
179 集中的に転送されるというバグが発生した。しかもそのようなバグは通常の逐次デバッガを用いた
|
|
|
180 デバッグ手法では、パケット集中を行っている複数のノードに対して複合的なバグ原因を検証することは
|
|
|
181 困難である。やはりこのような事態をデバッグするには従来の逐次デバッグとは異なる、分散デバッグ
|
|
5
|
182 インターフェースをもってデバッグを行う事が必要と考える。
|
|
4
|
183
|
|
|
184 \subsubsection{大量のパケットの送信}
|
|
|
185 前述した通信の集中とは逆に、大量のパケットを単体、または複数のノードに対して通常とは異なる
|
|
|
186 量で送信するバグも起こりうる。このような場合、大量のパケットによる多ノードへの通信集中はもち
|
|
|
187 ろん、送信したノードからのACKnowledgementが大量にネットワーク内に流れる事による、通信効率の
|
|
|
188 低下や輻輳の発生を生み出す可能性がある。この問題をデバッグする為には、
|
|
|
189 プログラムが停止してからではデバッグできない事から、
|
|
5
|
190 輻輳を発生させているプロトコルを動的に検知する必要がある。%###シスコのルーターはそうやってる###
|
|
4
|
191 やはり、この場合も通常の逐次デバッガでは検知が困難なことから、分散デバッグインターフェースを
|
|
|
192 用いてデバッグを行う事が望ましいと考える。
|
|
|
193
|
|
0
|
194
|
|
3
|
195 \subsection{スナップショットによる分散デバッグ}
|
|
5
|
196 %スナップショットがあれば二分法が使える、量はかなり多い、デッドロックの検出も可能、循環した依存性の検出
|
|
|
197 %分散デバッガでおかしなぶぶんを見つけて、入力タプルと出力タプルを特定
|
|
|
198 %そうすれば逐次型でデバッグできる
|
|
|
199 %重要なのはスナップショット、便利
|
|
|
200 %分散デバッグアルゴリズム自体がスケールしなければいけない、一カ所にデータを集めるのはいけない
|
|
|
201
|
|
4
|
202 現在主に用いられている単体の逐次デバッガは分散環境用に作られていないことから、
|
|
|
203 分散環境でのデバッグの場合、１プロセスに対してデバッガを動かすか、
|
|
|
204 複数プロセスに対してそれぞれデバッガを動かしてデバッグを行うかの
|
|
|
205 どちらかのスタイルがとられると述べたが、これではデバッグすべきプロセスが増えるとその
|
|
|
206 手間はかなりの物になり、現実的なデバッグ手法とは言えない。
|
|
3
|
207
|
|
4
|
208 また、分散プログラム環境下ではプログラム状態の非決定性が存在するため通常のデバッグには無い
|
|
|
209 問題があることも述べた。
|
|
|
210 シーケンシャルなデバッグ手法では、通信の到着順序によっても分岐が変化してしまうことから、
|
|
|
211 デバッグ対象のエラーに対して再現性を確保するのが難しいという問題である。
|
|
|
212 通常、分散環境下でのデバッグではこれらの点をふまえて、
|
|
0
|
213
|
|
4
|
214 \begin{itemize}
|
|
|
215 \item {通信におけるプログラムの状態が決定的になるようテストする}
|
|
|
216 \item {非決定性をシミュレートする}
|
|
|
217 \item {バリア同期で通信を止めてメモリ等の状態を調べる}
|
|
|
218 \item {各ノードでスナップショットを取得し、ログを解析する}
|
|
|
219 \end{itemize}
|
|
|
220
|
|
|
221 といった方法がとられる。
|
|
|
222
|
|
|
223 今回、Federated Lindaを用いた分散プログラム開発の為のデバッグインターフェースを考えるにあたって、
|
|
|
224 上記のうちから「各ノードでスナップショットを取得し、ログを解析する」という手法が最も適している
|
|
|
225 と考える。
|
|
|
226
|
|
5
|
227 その理由は、スナップショットを用いる事で、Federated Lindaにおける各ノードの通信を止める事無く
|
|
|
228 デバッグに必要なプログラムの状態を確認できるという点と、各ノードの大域的な状態を保存する事で
|
|
|
229 先に述べた「分散アルゴリズムにおいてデバッグすべき対象」をそれぞれデバッグすることが可能となる
|
|
|
230 からである。
|
|
|
231
|
|
|
232 以下で大域的な状態とはどのような物かを説明し、どのようにスナップショットを用いたデバッグインタ
|
|
|
233 ーフェースを用いるべきかを説明する。
|
|
|
234
|
|
|
235 \subsubsection{大域的なプログラム状態とは}
|
|
6
|
236 Federated Lindaにおける大域的なプログラム状態には二つの要素があり、各ノードのメモリ状態
|
|
|
237 （あるいはそれに類するデータ構造）を持つ事を第一としている。
|
|
|
238 このメモリ状態を各スナップショットでのタイミングごとに正確に
|
|
5
|
239 取得することにより、プログラムの大域変数や局所変数を用いたバグの特定を可能とする。
|
|
|
240
|
|
|
241 例えば、
|
|
|
242 先に述べた様なデッドロックの原因となる排他ロックの要求及び保持を検出する検出器の作成を行い、
|
|
|
243 スナップショットのログからデッドロックの追跡を行う事。または、二分法を用いてバグの存在するプロ
|
|
|
244 グラムの実行ステートメントとプログラム状態を取得する事が可能となる。
|
|
|
245
|
|
|
246 また、大域的なプログラム状態の要素として第二に、スナップショットを取るタイミングで実行中の
|
|
|
247 プロセスが発行した通信に対する状態についても取得すべきと考える。スナップショット取得のタイミングで
|
|
|
248 考えられる通信の状態は４つのパターンに分類され、そのパターンとは、
|
|
|
249 \\
|
|
|
250 \begin{itembox}[l]{-}
|
|
|
251 {\large
|
|
|
252 \begin{center}
|
|
|
253 \begin{verbatim}
|
|
|
254 スナップショット取得のタイミング = T
|
|
6
|
255 通信受信先でのスナップショット取得のタイミング = T'
|
|
5
|
256 \end{verbatim}
|
|
|
257 \end{center}
|
|
|
258 }
|
|
|
259 \end{itembox}
|
|
|
260
|
|
|
261 とすると、
|
|
|
262 \begin{itembox}[l]{-}
|
|
|
263 \begin{itemize}
|
|
|
264 \item {Tの前にパケットを送信し、T'よりも早くパケットを受け取る場合}
|
|
|
265 \item {Tの前にパケットを送信し、T'よりも遅くパケットを受け取る場合}
|
|
|
266 \item {Tの後にパケットを送信し、T'よりも早くパケットを受け取る場合}
|
|
|
267 \item {Tの後にパケットを送信し、T'よりも遅くパケットを受け取る場合}
|
|
|
268 \end{itemize}
|
|
|
269 \end{itembox}
|
|
|
270
|
|
|
271 という４つのパターンである。
|
|
|
272
|
|
|
273 この、スナップショット取得のタイミングに対する通信の状態は、プロセスの再現性や、
|
|
|
274 プロセスの状態がある時点でどのように保たれているかを検知する上での同期処理に密接に関わってくる。
|
|
|
275 通信の状態を同期する処理が行えなければ、ネットワークを介し他のノードと通信を行っている分散
|
|
|
276 プログラムの大域的状態を取得する事は、プログラム状態の決定性に欠けることとなる。
|
|
|
277 よって、分散環境でのスナップショットを考えるにあたっては、上記４パターン通信状態を
|
|
|
278 どのように同期するかが重要である。
|
|
|
279
|
|
|
280 \subsubsection{スナップショットを用いた分散デバッグ手法}
|
|
|
281 %スナップショットがあれば二分法が使える、量はかなり多い、デッドロックの検出も可能、循環した依存性の検出
|
|
|
282 %分散デバッガでおかしなぶぶんを見つけて、入力タプルと出力タプルを特定
|
|
|
283 %そうすれば逐次型でデバッグできる
|
|
|
284
|
|
|
285 ここまで、スナップショットを用いて分散デバッグを行う事と、そのための大域的プログラム状態について
|
|
|
286 説明した。ここでは、分散環境で取得したスナップショットをどのように用いてデバッグを行うべきかを
|
|
|
287 検討する。
|
|
|
288
|
|
6
|
289 \subsubsection{スナップショットのモニターツールと逐次デバッガによるデバッグ}
|
|
|
290 スナップショットを取得した場合、そのスナップショット・ログは膨大である。
|
|
|
291 よって、実際にスナップショット・ログからデバッグを行う為には様々な切り口で
|
|
|
292 情報を取捨選択できるモニターツールが必要であると考える。
|
|
|
293 図\ref{snapdeb}にスナップショットのモニタツールを用いたデバッグの様子を示す。
|
|
5
|
294
|
|
6
|
295 \begin{figure}[htbp]
|
|
|
296 \begin{center}
|
|
|
297 \includegraphics[width=12cm]{fig/pdf/snapdeb.pdf}
|
|
|
298 \caption{スナップショット・ログを用いたデバッグ}
|
|
|
299 \label{snapdeb}
|
|
|
300 \end{center}
|
|
|
301 \end{figure}
|
|
|
302
|
|
|
303 上記の図ではスナップショット・ログより、大域的プログラム状態の項で
|
|
|
304 説明したプログラムのメモリー状態とスナップショット取得のタイミングにおける通信状態を同期させる
|
|
|
305 ことによってFederated Lindaの大域的状態を取得している。
|
|
|
306 また、同期されたスナップショット・ログをモニタツールという、ユーザーが必要なデバッグ情報を取捨
|
|
|
307 選択するツールを用いる事を考える。ユーザーはモニタツールを用いて（例えば二文法によるバグ箇所の
|
|
|
308 検知などを利用）、どのプロセスから出力と入力があったタプルにバグの原因があるのかを特定するこ
|
|
|
309 とができる。そうすれば、その後のバグの修正においては逐次デバッガによるデバッグが可能となる。
|
|
|
310
|
|
|
311 \subsection{分散デバッグ機能のスケーラビリティ}
|
|
|
312 全ノードに対してデバッグプロセスを走らせてデバッグを行うような
|
|
|
313 手法は、デバッグのインターフェースにおけるスケーラビリティを考慮してはいない。
|
|
|
314
|
|
|
315 事実、システム資源の異なるノードに対してネットワークを介したリモートデバッグの手法は
|
|
|
316 数多く開発されていても、それが大規模システムを想定した分散プログラムに対してスケーラビリティを
|
|
|
317 保ったままデバッグ可能という解を得てはいない。
|
|
|
318
|
|
|
319 Federated Lindaはタプルのリレーという、より分散プログラムを意識したモデルであることから、デバッグ
|
|
|
320 インターフェースの大域的状態の取得にもスケーラビリティを持った実装を目指す。
|
|
|
321 その基本的なアイデアは、デバッグ情報を取得するインターフェースに対してもLindaプロトコルによるタプ
|
|
|
322 ルの伝搬を利用して実装するというものである。
|
|
|
323
|
|
|
324 下図\ref{FDLindaDebug}に示すように、Federated Lindaを用いたデバッグインターフェースは、デバッガ
|
|
|
325 プロセスからあるノードに対してデバッグ情報の取得を指示するオペレーションを発行し、デバッグ情報の
|
|
|
326 取得を行うデバッグプロトコルとしてタプル間を伝搬させる。
|
|
|
327 デバッガが受け取る結果はFederared Linda内のスナップショットとしての大域的状態であり、それを元に
|
|
|
328 デバッグを行う。このような仕組みをとる事で、大規模な分散プログラム環境であってもスケーラビリティ
|
|
|
329 を保ったままデバッグを行う事が可能となる。
|
|
|
330
|
|
|
331 \begin{figure}[htbp]
|
|
|
332 \begin{center}
|
|
|
333 \includegraphics[width=14cm]{fig/pdf/FDLindaDebug.pdf}
|
|
|
334 \caption{スケーラビリティを意識したデバッグインターフェース}
|
|
|
335 \label{FDLindaDebug}
|
|
|
336 \end{center}
|
|
|
337 \end{figure}
|
|
|
338
|
|
|
339 \section{通信状態デバッグインターフェースの実装}
|
|
|
340 ここまで、Federated Lindaを用いた分散環境環境における分散デバッグインターフェースの機能の検討
|
|
|
341 を行った。その結果、Federated Lindaで用いられるべき分散デバッグインターフェースはスナップショット
|
|
|
342 を用いて、デッドロック、ライブロック、スケーラビリティ、通信の集中、大量のパケットの送信、といった
|
|
|
343 要素のデバッグを行う事が必要との結論を得た。
|
|
|
344
|
|
|
345 しかし、検討したスナップショットでのデバッグインターフェースの実装の為には、現実装の
|
|
|
346 Federated Lindaで用いられるProtocol Engineには更なる改良が必要である。なぜならば、現在のProtocol
|
|
|
347 Engineはルーティングテーブルを内部データとして保持することから、Federated Lindaの大域的状態を
|
|
|
348 取得するにはProtocol Engineまでのスナップショットが必要となるからである。
|
|
|
349 これを解消する為にはProtocol Engineの内部状態をステートレスに実装し、その挙動はやり取りするXML
|
|
|
350 に全て埋め込むという実装が求められる。
|
|
|
351
|
|
|
352 本論文ではスナップショットではなく、前述した分散アルゴリズムにおいてデバッグすべき対象のうちから、
|
|
|
353 通信の集中を検知するデバッグインターフェースについて実装を行った。
|
|
|
354 このデバッグインターフェースを用いる事により、３章で提示したCompact Routingを用いるFederated Linda
|
|
|
355 において、meshトポロジで起こったデバッグ困難な通信の集中を伴う状態の検知を行う事を目標とする。
|
|
|
356 以下にその実装の詳細を示す。
|
|
5
|
357
|
|
4
|
358
|
|
3
|
359
|
|
|
360 \subsection{Java版Linda サーバーへの機能実装}
|
|
0
|
361 \begin{center}
|
|
|
362 \begin{itembox}[l]{ComDebug機能拡張部分}
|
|
|
363 {\footnotesize
|
|
|
364 \begin{verbatim}
|
|
|
365 if (debug) {
|
|
|
366 System.out.println("data from : "+key.channel());
|
|
|
367 }
|
|
|
368 if((mode == '!') || (len == 0)) {
|
|
|
369 Connection_Close(key);
|
|
|
370 com_debug.reportCh_remove(key, reportCh_list);
|
|
|
371 }
|
|
|
372 else if(mode == PSX_CHECK) {
|
|
|
373 Check(key, command);
|
|
|
374 }
|
|
|
375 else if(mode == PSX_IN || mode == PSX_RD){
|
|
|
376 In_Rd(key, command, mode);
|
|
|
377 }
|
|
|
378 else if (mode == PSX_WAIT_RD) {
|
|
|
379 Wait_Rd(key, command, mode);
|
|
|
380 } else if(mode == PSX_OUT) {
|
|
|
381 Out(command, data);
|
|
|
382 } else {
|
|
|
383 System.out.println("Uncorrect buffer");
|
|
|
384 System.exit(1);
|
|
|
385 }
|
|
|
386
|
|
|
387 //COM_DEBUG
|
|
|
388 if(id > PRIVILEGED_ID_START && id < PRIVILEGED_ID_END){
|
|
|
389 ComDebug.addChannel(key, reportCh_list);
|
|
|
390 }
|
|
|
391 //DEBUG用カウンタ
|
|
|
392 ComDebug.Com_inc(key, com_Loggingtable, mode);
|
|
|
393 //DEBUG用レポート
|
|
|
394 ComDebug.Report(reportCh_list, command, com_Loggingtable.toString());
|
|
|
395
|
|
|
396 \end{verbatim}
|
|
|
397 }
|
|
|
398 \end{itembox}
|
|
|
399 \end{center}
|
|
|
400
|
|
|
401
|
|
3
|
402 \subsection{視覚的に通信状態を確認するツールの開発}
|
|
0
|
403 \begin{figure}[htbp]
|
|
|
404 \begin{center}
|
|
2
|
405 \includegraphics[width=10cm]{fig/pdf/visual01.pdf}
|
|
0
|
406 \caption{通信量のグラフィカルな表示ツール}
|
|
|
407 \label{visual01}
|
|
|
408 \end{center}
|
|
|
409 \end{figure}
|
|
|
410
|
|
3
|
411 \section{Compact Rotingの実装を用いた評価}
|
|
0
|
412
|
|
3
|
413 \subsection{通信量のスケーラビリティ}
|
|
|
414
|
|
|
415 \subsection{評価}
|
|
|
416
|
|
|
417 \section{考察}
|
|
|
418
|
|
|
419
|
|
|
420
|
|
|
421 %\subsection{Federated Lindaのデバッグ}
|
|
|
422 %現在主流なデバッグ手法はプレークポイント等を用いてプログラムを停止し、その地点からの前後でプログ
|
|
|
423 %ラムの状態を確認する、二分法によるデバッグ手法である。
|
|
|
424 %Federated Lindaを用いた開発環境においてもこのような手法は大変有効ではあるが、通信の状態によって、
|
|
|
425 %デバッグが可能な場合と困難な場合とが存在する。
|
|
0
|
426
|
|
3
|
427 %以下の図\ref{seqdeb}に通常用いられるデバッグが有効なFederated Lindaの通信状態を示す。
|
|
|
428
|
|
|
429
|
|
|
430 %\begin{figure}[htbp]
|
|
|
431 %\begin{center}
|
|
|
432 %\includegraphics[width=8cm]{fig/pdf/seqdeb.pdf}
|
|
|
433 %\caption{デバッグ可能なFederated Lindaの通信}
|
|
|
434 %\label{seqdeb}
|
|
|
435 %\end{center}
|
|
|
436 %\end{figure}
|
|
|
437
|
|
|
438 %\begin{figure}[htbp]
|
|
|
439 %\begin{center}
|
|
|
440 %\includegraphics[width=10cm]{fig/pdf/nonseqdeb.pdf}
|
|
|
441 %\caption{デバッグが困難なFederated Lindaの通信}
|
|
|
442 %\label{nonseqdeb}
|
|
|
443 %\end{center}
|
|
|
444 %\end{figure}
|
|
0
|
445
|
|
3
|
446
|
|
|
447 %\subsection{分散環境におけるデバッグ}
|
|
|
448
|
|
|
449
|
|
|
450 %今回は、Fedarated Lindaを用いた分散プログラム開発としてCompact Routingを用いるFederated Lindaの
|
|
|
451 %分散アルゴリズムの開発を行った経験にて、通信状態や通信量をデバッグできる機能が必要であるとの知見
|
|
|
452 %を得たことから、通信量のデバッグインターフェースを実装する。
|
|
|
453 %このデバッグインターフェースはLinda サーバーやクライアント(Protocol Engine)間での通信を止めずに、
|
|
|
454 %動いているFederated Lindaの通信量をデバッグする（すなわち、通信量のスケーラビリティを見る）
|
|
|
455 %インターフェースである。
|
|
|
456
|
|
|
457 %\subsection{Java版タプルサーバーへの通信量デバッグ機能の実装}
|
|
0
|
458
|
|
|
459
|
|
|
460
|
|
3
|
461 %\newpage
|
|
|
462 %\subsection{通信ログ情報のグラフィカルな表示ツール}
|
|
0
|
463
|
|
3
|
464 %\section{通信量デバッグインターフェースによる評価} |
