[論文レビュー] On using Tracer Driver for External Dynamic Process Observation

Pierre Deransart|ArXiv.org|Jan 17, 2007

Distributed and Parallel Computing Systems被引用数 3

ひとこと要約

本論文は、外部の動的プロセスを観察するための「フルトレース」モデルを提案する。このモデルでは、プロセスがトレーサドライバを介して実行時におけるすべての潜在的に有用な情報をブロードキャストするようにインストルメント化される。トレーサドライバは複数の独立したアナライザーにデータを選択的に供給する。このアプローチにより、トレース生成を集中化することで重複するインストルメントーションを削減し、効率的でオンデマンドの分析を可能にする。制約解決ワークロードにおけるトレース圧縮とワークロード分散を通じて、性能向上が示されている。

ABSTRACT

One is interested here in the observation of dynamic processes starting from the traces which they leave or those that one makes them produce. It is considered here that it should be possible to make several observations simultaneously, using a large variety of independently developed analyzers. For this purpose, we introduce the original notion of ``full trace'' to capture the idea that a process can be instrumented in such a way that it may broadcast all information which could ever be requested by any kind of observer. Each analyzer can then find in the full trace the data elements which it needs. This approach uses what has been called a "tracer driver" which completes the tracer and drives it to answer the requests of the analyzers. A tracer driver allows to restrict the flow of information and makes this approach tractable. On the other side, the potential size of a full trace seems to make the idea of full trace unrealistic. In this work we explore the consequences of this notion in term of potential efficiency, by analyzing the respective workloads between the (full) tracer and many different analyzers, all being likely run in true parallel environments. To illustrate this study, we use the example of the observation of the resolution of constraints systems (proof-tree, search-tree and propagation) using sophisticated visualization tools, as developed in the project OADymPPaC (2001-2004). The processes considered here are computer programs, but we believe the approach can be extended to many other kinds of processes.

研究の動機と目的

• 複数の独立したアナライザーが、重複するインストルメントーションなしに、1つの動的プロセスを同時に観察できるようにすること。
• 包括的なトレースを生成する際のスケーラビリティの課題に対処するため、あらゆる可能な観測データをキャプチャする「フルトレース」抽象化を導入すること。
• 特に制約解消のような複雑なプロセスを対象として、フルトレースシステムの実用性と効率性を評価すること。
• トレーサ、トレーサドライバ、およびアナライザー間でのワークロード分散が、パフォーマンスオーバーヘッドを最小限に抑える方法を検討すること。
• トレース圧縮と通信最適化が、実世界でのフルトレースシステムの実用化に果たす役割を評価すること。

提案手法

• 動的プロセス内のすべての状態変化およびアクションの包括的ログである「フルトレース」の概念を導入する。これは、任意のアナライザーが関心を持つ可能性のあるすべてのデータをキャプチャする。
• インストルメント化されたプロセスと外部アナライザーの間を仲介するミドルウェアコンponentとしてのトレーサドライバを提案する。このドライバは、要求に応じてトレース要素をフィルタリングし、必要なデータを供給する。
• データ転送量を制限し、特に高頻度のシナリオにおいてオーバーヘッドを低減するために、フルトレースのインクリメンタルかつ圧縮された表現を用いる。
• アナライザーが特定のトレースイベントおよび属性を要求し、ドライバが関連するデータのみを返すクライアント・サーバアーキテクチャを採用する。
• 通信帯域幅と処理負荷を最小限に抑えるために、インクリメンタル属性や抽象メタデータなどのトレース圧縮技術を適用する。
• 複雑で変化し続けるデータ構造が一般的な、OADymPPaCおよびDiSCiPlプロジェクトからの実際の制約解決ワークロードを用いて、システムを評価する。

実験結果

リサーチクエスチョン

• RQ1 複数のアナライザーが存在する並列環境において、フルトレースが効率的に生成され、消費できる範囲はどの程度か？
• RQ2 トレーサ、トレーサドライバ、およびアナライザー間でのワークロード分散が、全体のシステムパフォーマンスに与える影響はいかほどか？
• RQ3 トレーサドライバによるトレース圧縮と選択的データ配信によって、どのようなパフォーマンス向上が達成できるか？
• RQ4 トレースサイズや処理オーバーヘッドが大きくなると、どのような状況でフルトレースアプローチが実用的でなくなるか？
• RQ5 アナライザーとトレーサドライバ間の通信プロトコルを、遅延とデータ量を最小限に抑えつつ、分析の正確性を保持できるように設計するにはどうすればよいか？

主な発見

• フルトレースの概念により、複数のアナライザーが同じプロセスを観察する際、別々のトレーサを必要とせず、インストルメントーションのオーバーヘッドを顕著に削減できる。
• トレーサドライバは、処理コストの大部分をトレーサからアナライザーに移動させることに成功し、システムのスケーラビリティと効率性を維持できる。
• 最悪ケース（フルトレースが個々のアナライザーの縮小トレースの和集合に等しい場合）であっても、知的なフィルタリングにより、トレーサドライバの導入が依然として顕著なパフォーマンス向上をもたらす。
• パフォーマンスのボトル neck は、特に大規模かつ複雑なトレースを処理する際、トレーサよりもアナライザーに起因する傾向が強い。
• インクリメンタル属性や抽象メタデータを含むトレース圧縮技術は、通信オーバーヘッドを顕著に低減し、システムの応答性を向上させる。
• トレースの意味的解釈は依然として課題であり、特に形式的意味論が事前に入手できない複雑または非決定的システムでは顕著である。