ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Oracle Solaris Studio 12.3: パフォーマンスアナライザ Oracle Solaris Studio 12.3 Information Library (日本語) |
時間ベースのプロファイリングとハードウェアカウンタオーバーフローのプロファイリング
<no Java callstack recorded> 関数
ハードウェアカウンタオーバーフロープロファイルに関連する関数
データ収集の実行による出力は実験であり、さまざまな内部ファイルとサブディレクトリを持つディレクトリとしてファイルシステム内に格納されます。
すべての実験には、次の 3 つのファイルが含まれています。
ログファイル (log.xml)。どのようなデータが収集されたか、各種コンポーネントのバージョン、ターゲットが存続している間の各種イベントのレコード、およびターゲットのワードサイズなどに関する情報が含まれている XML ファイル。
マップファイル (map.xml)。どのようなロードオブジェクトがターゲットのアドレス空間に読み込まれたかに関する時間従属情報と、それらのロードオブジェクトが読み込まれたか読み込み解除された時間を記録した XML ファイル。
オーバービューファイル。実験内のあらゆる標本点で記録された使用情報を含むバイナリファイル。
また、実験にはプロセスが存続している間のプロファイルイベントを表すバイナリデータファイルがあります。各データファイルには、Interpreting Performance Metricsで説明しているように、一連のイベントがあります。「パフォーマンスメトリックの解釈」データの種類ごとに個別のファイルが使用されますが、各ファイルはターゲット内のすべてのスレッドで共有されます。
時間ベースのプロファイルまたはハードウェアカウンタオーバーフローのプロファイルの場合、データはクロック刻みまたはカウンターオーバーフローによって呼び出されたシグナルハンドラに書き込まれます。同期トレース、ヒープトレース、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 のコード文字が追加される。
コード文字のあとに、fork または exec のインデックスを示す数字が追加される。この数字は、プロセスが正常に開始されたかどうかに関係なく適用される。
実験接尾辞 .er を付加して実験名が完成する。
たとえば親プロセスの実験名が test.1.er の場合、3 回目の fork の呼び出しで作成された子プロセスの実験は test.1.er/_f3.er となります。この子プロセスが新しいイメージを実行した場合、対応する実験名は test.1.er/_f3_x1.er となります。派生実験は親の実験と同じファイルから構成されていますが、派生実験を持たず (すべての派生は親の実験内のサブディレクトリで表される)、アーカイブサブディレクトリを持っていません (すべてのアーカイブが親の実験内へ行われる)。
MPI プログラムのデータはデフォルトでは test.1.er に収集され、MPI プロセスからのすべてのデータはサブ実験に収集されます (ランクごとに 1 つ)。コレクタは MPI ランクを使用して、M_rm.er の形式のサブ実験名を作成します。ここで、m は MPI ランクです。たとえば、MPI ランク 1 の実験データは、test.1.er/M_r1.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 という名前が付けられます。
ターゲットが動的な関数を作成する実験には、map.xml ファイル内に動的な関数を記述する追加レコードと、動的な関数の実際の命令のコピーを含む追加ファイル dyntext があります。動的な関数の注釈付き逆アセンブリを生成するには、このコピーが必要です。
Java 実験の map.xml ファイル内には、その内部処理用に JVM ソフトウェアで作成された動的な関数用と、ターゲット Java メソッドの動的にコンパイルされた (HotSpot) バージョン用の追加レコードがあります。
さらに、Java 実験には、ユーザーの呼び出されたすべての Java クラスに関する情報を含む JAVA_CLASSES ファイルも存在します。
Java トレースデータは、libcollector.so の一部である JVMTI エージェントを使用して記録されます。エージェントは、記録されたトレースイベントへマップされるイベントを受け取ります。このエージェントはまた、JAVA_CLASSES ファイルや、map.xml ファイル内の Java でコンパイルされたメソッドレコードを書き込むために使用される、クラスの読み込みや HotSpot コンパイルのためのイベントも受信します。
ユーザーモードのターゲット上の実験は、次の 3 種類の方法で記録できます。
collect コマンド
dbx によるプロセスの生成
dbx による実行中のプロセスからの実験の作成
アナライザ GUI の「パフォーマンスコレクタ」ウィンドウでは、collect 実験が実行されます。
collect コマンドを使用して実験を記録する場合、collect ユーティリティーは実験ディレクトリを作成して LD_PRELOAD 環境変数を設定することにより、libcollector.so やその他の libcollector モジュールが確実にターゲットのアドレス空間に事前に読み込まれるようにします。collect ユーティリティーは、その後、libcollector.so に実験名を知らせるための環境変数とデータ収集オプションを設定し、ターゲットをその上で実行します。
libcollector.so および関連モジュールが、すべての実験ファイルを書き込みます。
データ収集を有効にした状態で dbx を使用してプロセスを起動すると、dbx は実験ディレクトリも作成し、libcollector.so が事前に読み込まれるようにします。dbx は最初の命令の前のブレークポイントでプロセスを停止し、次にデータ収集を開始するために libcollector.so 内の初期化ルーチンを呼び出します。
Java 実験データが dbx で収集できないのは、dbx がデバッグのために Java Virtual Machine Debug Interface (JVMDI) エージェントを使用し、そのエージェントがデータの収集に必要な Java Virtual Machine Tools Interface (JVMTI) エージェントと共存できないからです。
dbx を使用して実行中のプロセスで実験を開始すると、dbx は実験ディレクトリを作成しますが、LD_PRELOAD 環境変数を使用できません。dbx は対話式関数呼び出しをターゲット内に行なって libcollector.so を開き、次にプロセスを作成する場合と同様に libcollector.so の初期化ルーチンを呼び出します。データは、collect による実験の場合と同様に libcollector.so とそのモジュールによって書き込まれます。
プロセスが開始したときに libcollector.so はターゲットアドレス空間になかったので、ユーザー呼び出し可能関数 (同期トレース、ヒープトレース、MPI トレース) に対する割り込み処理に依存するデータ収集は機能しない場合があります。一般に、シンボルはすでに基礎的な関数に分解されているので、割り込み処理は行えません。さらに、派生プロセスの次も割り込み処理に依存し、実行中プロセスで dbx により作成された実験に対して適切に機能しません。
dbx でプロセスを開始する前、または dbx で実行中プロセスに接続する前に明示的に libcollector.so を事前読み込みした場合は、トレースデータを収集できます。