データ収集の実行による出力は実験であり、さまざまな内部ファイルとサブディレクトリを持つディレクトリとしてファイルシステム内に格納されます。
すべての実験には、次の 3 つのファイルが含まれています。
ログファイル (log.xml)。収集されたデータの種類、各種コンポーネントのバージョン、ターゲットが存続している間の各種イベントのレコード、およびターゲットのワードサイズに関する情報が含まれている XML ファイル。
マップファイル (map.xml)。ターゲットのアドレス空間にどのようなロードオブジェクトがロードされたかに関する時間依存の情報、およびそれらのロードオブジェクトがロードまたはアンロードされた時間を記録した XML ファイル。
概要ファイル。実験内のあらゆる標本ポイントで記録された使用情報を含むバイナリファイル。
また、実験にはプロセスが存続している間のプロファイルイベントを表すバイナリデータファイルがあります。パフォーマンスメトリックの解釈で説明されているように、各データファイルには一連のイベントが含まれています。データの種類ごとに個別のファイルが使用されますが、各ファイルはターゲット内のすべてのスレッドで共有されます。
クロックプロファイリングまたはハードウェアカウンタオーバーフロープロファイリングの場合、データは、クロックティックまたはカウンタオーバーフローによって呼び出されたシグナルハンドラで書き込まれます。同期トレース、ヒープトレース、I/O トレース、MPI トレース、または OpenMP トレースの場合、データは、通常ユーザーによって呼び出されたルーチンで LD_PRELOAD 環境変数によって割り込まれた libcollector ルーチンから書き込まれます。そのような割り込み処理ルーチンは部分的にデータレコードを記入したあと、通常のユーザー呼び出しルーチンを呼び出し、ルーチンが復帰したときにデータレコードの残りの部分を記入し、データファイルにレコードを書き込みます。
すべてのデータファイルはメモリーマップされ、ブロック単位で書き込まれます。レコードは常に有効なレコード構造を持つように記入されるので、実験は書き込み中に読み取ることができます。このバッファー管理の方針は、スレッド間の競合や直列化を最小限に抑えるように設計されています。
オプションで、notes という名前の ASCII ファイルを実験に含めることができます。このファイルは、 collect コマンドに -C comment 引数を使用すると、自動的に作成されます。実験の作成後、ファイルを手動で編集または作成できます。ファイルの内容は、実験のヘッダーの先頭に付加されます。
各実験には archives ディレクトリがあり、このディレクトリには、map.xml ファイル内で参照されている各ロードオブジェクトについて記述したバイナリファイルがあります。これらのファイルは、データ収集の終了時に実行される er_archive ユーティリティーによって作成されます。プロセスが異常終了すると、er_archive ユーティリティーが呼び出されないことがあります。その場合は、er_print ユーティリティーまたはパフォーマンスアナライザが、その実験で最初に呼び出されたときにアーカイブファイルを書き込みます。
アーカイブディレクトリにはまた、実験をアーカイブするために使用されるオプションに応じて、共有オブジェクトまたはソースファイルのコピーを含めることもできます。
サブ実験は、派生プロセスをたどったり、MPI 実験を収集したり、ユーザープロセスでカーネルをプロファイルしたりする場合など、複数のプロセスがプロファイルされるときに作成されます。
派生プロセスは、その実験を親実験のディレクトリ内のサブディレクトリに書き込みます。これらの新しいサブ実験には、次のように、その系統を示す名前が付けられます。
作成者の実験名にアンダースコアが付加される。
fork には f、exec には x、そのほかの派生実験には c のコード文字が追加される。Linux では、C は clone(2) によって生成された子孫に使用されます。
コード文字のあとに、fork または exec のインデックスを示す数字が追加される。
実験接尾辞 .er を付加して実験名が完成する。
ユーザープロセスでは、親プロセスの実験名が test.1.er である場合、その 3 番目の fork によって作成された派生プロセスの実験は test.1.er/_f3.er になります。その派生プロセスが新しいイメージを実行した場合、対応する実験名は test.1.er/_f3_x1.er になります。派生実験は親の実験と同じファイルから構成されていますが、派生実験を持たず (すべての派生は親の実験内のサブディレクトリで表される)、アーカイブサブディレクトリを持っていません (すべてのアーカイブが親の実験内へ行われる)。
カーネル上の実験には、デフォルトでは test.1.er ではなく、ktest.1.er という名前が付けられます。データがユーザープロセスでも収集されるときは、カーネル実験には後続のユーザープロセスごとのサブ実験が含まれます。カーネルサブ実験には、_process-name_PID_process-id.1.er の形式を使用して名前が付けられます。たとえば、プロセス ID 1264 で実行されている sshd プロセス上で実行される実験には、ktest.1.er/_sshd_PID_1264.1.er という名前が付けられます。
MPI プログラムのデータはデフォルトでは test.1.er に収集され、MPI プロセスからのすべてのデータはサブ実験に収集されます (ランクごとに 1 つ)。コレクタは、MPI ランクを使用して、M_rm.er の形式のサブ実験名を構築します。ここで、m は MPI ランクです。たとえば、MPI ランク 1 の実験データは、test.1.er/M_r1.er ディレクトリ内に記録されます。
ターゲットが動的関数を作成する実験では、map.xml ファイル内にこれらの関数を記述した追加レコードが存在します。追加ファイル dyntext には、動的関数の実際の命令のコピーが含まれています。動的な関数の注釈付き逆アセンブリを生成するには、このコピーが必要です。
Java 実験では、map.xml ファイル内には、その内部処理用に JVM ソフトウェアで作成された動的関数用と、ターゲット Java メソッドの動的にコンパイルされた (HotSpot) バージョン用の追加レコードがあります。
さらに、Java 実験には、ユーザーの呼び出されたすべての Java クラスに関する情報を含む JAVA_CLASSES ファイルが含まれています。
Java トレースデータは、libcollector.so の一部である JVMTI エージェントを使用して記録されます。エージェントは、記録されたトレースイベントへマップされるイベントを受け取ります。このエージェントはまた、JAVA_CLASSES ファイルの書き込みや、Java でコンパイルされたメソッドレコードの map.xml ファイルへの書き込みに使用される、クラスのロードや HotSpot コンパイルのためのイベントも受信します。
ユーザーモードのターゲット上の実験は、次の 3 種類の方法で記録できます。
collect コマンド
dbx によるプロセスの生成
dbx による実行中のプロセスからの実験の作成
パフォーマンスアナライザの「アプリケーションのプロファイル」ダイアログでは、collect 実験を実行します。
collect コマンドを使用して実験を記録する場合、collect ユーティリティーは実験ディレクトリを作成して LD_PRELOAD 環境変数を設定することにより、libcollector.so やその他の libcollector モジュールが確実にターゲットのアドレス空間に事前にロードされるようにします。collect ユーティリティーは、その後、libcollector.so に実験名を知らせるための環境変数とデータ収集オプションを設定し、ターゲットをその上で実行します。
libcollector.so および関連モジュールが、すべての実験ファイルを書き込みます。
データ収集を有効にした状態で dbx を使用してプロセスを起動すると、dbx は実験ディレクトリも作成し、libcollector.so が事前に読み込まれるようにします。dbx は最初の命令の前のブレークポイントでプロセスを停止し、次にデータ収集を開始するために libcollector.so 内の初期化ルーチンを呼び出します。
dbx はデバッグに Java Virtual Machine Debug Interface (JVMDI) エージェントを使用するため、dbx では Java 実験を収集できません。そのエージェントは、データ収集に必要な Java Virtual Machine Tools Interface (JVMTI) エージェントと共存できません。
dbx は実行中プロセスでの実験開始に使用すると実験ディレクトリを作成しますが、LD_PRELOAD 環境変数は使用できません。dbx はターゲットへの対話式関数呼び出しを行なって libcollector.so を開いたあと、プロセスを作成する場合と同様に libcollector.so の初期化ルーチンを呼び出します。データは、collect による実験の場合と同様に libcollector.so とそのモジュールによって書き込まれます。
このプロセスが開始されたときに libcollector.so はターゲットのアドレス空間に存在しなかったため、ユーザー呼び出し可能関数に対する割り込みに依存するデータ収集 (同期トレース、ヒープトレース、MPI トレース) はどれも機能しない可能性があります。一般に、シンボルは基盤となる関数にすでに解決されているため、割り込み処理は行えません。さらに、派生プロセスの次も割り込み処理に依存し、実行中プロセスで dbx により作成された実験に対して適切に機能しません。
dbx でプロセスを開始する前、または dbx を使用して実行中プロセスに接続する前に明示的に libcollector.so を事前ロードしている場合は、トレースデータを収集できます。