collect collect-arguments target target-arguments collect collect -V
collect コマンドはターゲットプロセスを実行し、そのプロセスのパフォーマンスデータとグローバルデータを記録します。パフォーマンスデータは、プロファイリングまたはトレース技法を使用して収集されます。このデータは、GUI プログラム (analyzer) またはコマンド行プログラム (er_print) を使用して検査できます。collect コマンドによって実行されるデータ収集ソフトウェアを、ここではコレクタと呼びます。
collect コマンドの 1 回の実行から得られたデータは実験と呼ばれます。実験は、ファイルシステムではディレクトリとして表され、そのディレクトリの内部にさまざまなファイルが含まれています。
target は、パフォーマンスデータを収集する対象となる実行可能ファイル (Java(TM) .jar ファイルまたは Java .class ファイル) のパス名です。(Java プロファイリングの詳細は、下記の「Java プロファイリング」を参照)。collect コマンドのターゲットである実行可能ファイルは、任意のレベルの最適化でコンパイルできますが、動的リンクを使用する必要があります。プログラムが静的にリンクされている場合、collect コマンドはエラーメッセージを出力します。analyzer または er_print を使用して注釈付きソースを表示するには、ターゲットを -g フラグでコンパイルするようにし、また削除しないようにしてください。
データ領域プロファイリングを有効にするには、実行可能ファイルを -xhwcprof -xdebugformat=dwarf -g フラグでコンパイルするようにしてください。これらのフラグは、C、C++、および Fortran コンパイラでのコンパイルに適用できますが、-xhwcprof フラグは SPARC[R] プラットフォームでのみ意味があります。その他のプラットフォームでは無視されます。これらのフラグでコンパイルされない場合、er_print の data_layout、data_single、および data_objects コマンドではデータが表示されません。ターゲットが -xhwcprof フラグなしでコンパイルされている場合でも、「メモリーオブジェクト」レポートにはデータが表示されます。下記の「データ領域プロファイリング」のセクションを参照してください。
collect コマンドは、次の方法を使用してターゲットを検索します。
指定されたターゲット名を持つファイルが存在し、実行権が設定されており、かつ ELF 実行可能ファイルである場合、collect コマンドは、そのファイルを現在のマシン上で実行できることを確認してから実行します。そのファイルが ELF 実行可能ファイルでない場合、collect コマンドは、そのファイルをスクリプトであると見なして実行します。
指定されたターゲット名を持つファイルは存在するが、実行権が設定されていない場合、collect は、そのファイルが Java[TM] jar ファイル (ターゲット名が .jar で終了) またはクラスファイル (ターゲット名が .class で終了) であるかどうかをチェックします。そのファイルが jar ファイルまたはクラスファイルである場合、collect は、ターゲットとして Java[TM] 仮想マシン (JVM) ソフトウェアを (必要なすべてのフラグとともに) 挿入し、その JVM マシンに関するデータを収集します。(「Java 仮想マシン」および「JVM」という用語は、Java[TM] プラットフォーム用の仮想マシンを意味します)。下記の「Java プロファイリング」のセクションを参照してください。
指定されたターゲット名を持つファイルが見つからない場合、collect は、現在のパスを検索して実行可能ファイルを探します。実行可能ファイルが見つかった場合、collect は、前述のようにそのファイルを確認します。
指定されたターゲット名のファイルが現在のパスにも見つからない場合、このコマンドは、その名前に文字列 .class が付加されたファイルを探します。そのクラス名を持つファイルが見つかった場合、collect は、前述のように JVM マシンを適切なフラグとともに挿入します。
これらのいずれの手順でもターゲットを見つけることができない場合、このコマンドは失敗します。
引数なしで呼び出された場合、collect は、実験のデフォルト構成を含む使用法のサマリーを出力します。
-h 引数のみで呼び出された場合、collect は、ハードウェアカウンタの情報を出力します。プロセッサがハードウェアカウンタオーバーフロープロファイリングをサポートしている場合、collect は、ハードウェアカウンタに関する情報を含む 2 つのリストを出力します。最初のリストには、「別名を付けた」ハードウェアカウンタが含まれています。2 番目のリストには、「raw」ハードウェアカウンタが含まれています。出力には、そのプロセッサについてのデフォルトの HWC 実験の指定も含まれています。詳細は、下記の「ハードウェアカウンタオーバーフロープロファイリング」のセクションを参照してください。
プロセッサがハードウェアカウンタオーバーフローの処理をサポートしていない場合は、出力にそれが示されます。
クロックベースのプロファイリングデータを収集します。option に使用できる値は次のとおりです。
クロックベースのプロファイリングを無効にします。
約 10 ミリ秒のデフォルトのプロファイリング間隔でのクロックベースのプロファイリングを有効にします。
約 100 ミリ秒の低分解能プロファイリング間隔でのクロックベースのプロファイリングを有効にします。
約 1 ミリ秒の高分解能プロファイリング間隔でのクロックベースのプロファイリングを有効にします。
n のプロファイリング間隔でのクロックベースのプロファイリングを有効にします。値 n には、マイクロ秒単位の値を示す u、またはミリ秒単位の値を示す m の接尾辞の付いた整数または浮動小数点数値を指定できます。接尾辞が使用されていない場合、値はミリ秒単位であると見なされます。
この値がクロックプロファイリングの最小値より小さい場合は、その値を最小値に設定します。この値がクロックプロファイリングの分解能の倍数でない場合は、クロック分解能のもっとも近い倍数に切り下げます。クロックプロファイリングの最大値を超えた場合は、エラーを報告します。負または 0 である場合は、エラーを報告します。
明示的な -p 引数が指定されておらず、かつカウントデータ、競合検出、デッドロックデータのいずれも指定されていない場合は、クロックベースのプロファイリングを有効にします。そのチップについてのデフォルトカウンタセットを高頻度または低頻度で要求する -h high または -h low が指定された場合、デフォルトのクロックプロファイリングも high または low に設定され、明示的な -p 引数が推奨されます。
クロックプロファイリングベースのデータ領域およびメモリー領域プロファイリングはサポートされなくなりました。サポートされているマシンはすべて、メモリー操作用のハードウェアカウンタを備えています。
ハードウェアカウンタオーバーフロー (HWC) プロファイリングデータを収集します。パラメータは次のいずれかです。
HW カウンタプロファイリングデータを収集しません。off が指定されている場合、ほかの -h 引数は指定できません。その他の値が指定されている場合は、複数の -h 引数を指定することができ、各引数のカウンタが使用されます。
特定のシステムに対して定義されているデフォルトのカウンタセットを使用します。そのセットは、collect -h の出力で示されます。すべてのシステムでデフォルトのカウンタセットが定義されているわけではありません。何も定義されていない場合は、-h on でエラーが生成されます。
特定のシステムで定義されたデフォルトのカウンタセットを使用しますが、高い頻度でプロファイルします。すべてのシステムでデフォルトのカウンタセットが定義されているわけではありません。何も定義されていない場合は、-h hi でエラーが生成されます。
特定のシステムで定義されたデフォルトのカウンタセットを使用しますが、低い頻度でプロファイルします。すべてのシステムでデフォルトのカウンタセットが定義されているわけではありません。何も定義されていない場合は、-h lo でエラーが生成されます。
指定された 1 つ以上のカウンタを使用してハードウェアカウンタオーバーフロープロファイルを収集します。サポートされるカウンタ (ctr_def から ctr_n_def) の最大数はプロセッサに依存します。現在のマシン上でほかのどの引数も指定せずに collect -h を実行することによって、現在のマシン上でのプロファイリングのためのハードウェアカウンタ定義の最大数を確認したり、使用可能なハードウェアカウンタの完全なリストやデフォルトのカウンタセットを表示したりすることができます。
各カウンタ定義の形式を次に示します。
[+|-]ctr[~attr=val]...[~attrN=valN][/reg#],[interval]
カウンタ定義の各オプションの意味は次のとおりです。
メモリー関連のカウンタに適用できるオプションパラメータ。+ は、データ領域およびメモリー領域プロファイリングデータを記録するようにリクエストします。- は、それを記録しないようにリクエストします。
メモリー関連のカウンタのタイプは、ほかのどのコマンド行引数も指定せずに collect -h コマンドを実行することによって取得されたカウンタリストで表示される load、store、または load-store です。このようなカウンタの一部には、precise というラベルも付けられます。
正確なカウンタの場合は、SPARC または x86 のどちらでも、+ は必要ありません。データ領域およびメモリー領域データがデフォルトで記録されます。- を指定すると、データ領域およびメモリー領域データが無効になります。
SPARC の場合のみ、正確でないメモリーカウンタに対して + を指定すると、collect は、オーバーフローをトリガーした命令とメモリー参照の仮想および物理アドレスを見つけることによってデータ領域データを収集します。このようなデータはデフォルトでは記録されず、それを無効にするために - は必要ありません。下記の「データ領域およびメモリー領域プロファイリング」のセクションを参照してください。
プロセッサ固有のカウンタ名。カウンタ名のリストは、ほかのどのコマンド行引数も指定せずに collect -h コマンドを実行することによって確認できます。ほとんどのシステムでは、カウンタがリストにない場合でも、そのカウンタを引き続き 16 進数 (0x1234) または 10 進数のどちらかの数値で指定できます。古いチップのドライバでは数値がサポートされませんが、最近のチップのドライバではサポートされています。カウンタを数値で指定する場合は、レジスタ番号も指定するようにしてください。使用する数値は、チップ固有の製造元のマニュアルに記載されています。マニュアルの名前は、collect -h の出力で指定されます。一部のカウンタは、ベンダー独自のマニュアルでしか説明されていません。
オプションの 1 つ以上の属性オプション。一部のプロセッサでは、属性オプションをハードウェアカウンタに関連付けることができます。プロセッサが属性オプションをサポートしている場合は、ほかのどのコマンド行引数も指定せずに collect -h を実行すると、attr に使用する属性名のリストも表示されます。val の値は、10 進数または 16 進数の形式で指定できます。16 進数の形式の数値は、数値の前に 0 と小文字の x が付加された C プログラムの形式 (0xhex_number) で指定します。カウンタ名に複数の属性が連結されます。attr の各名前の前には ~ が必要です。
カウンタに使用するハードウェアレジスタ。指定されていない場合、collect は、カウンタを使用可能な最初のレジスタに配置しようとします。その結果、レジスタの競合のために以降のカウンタを配置できない可能性があります。複数のカウンタを指定する場合は、各カウンタで異なるレジスタを使用する必要があります。使用可能なレジスタ番号のリストは、ほかのどのコマンド行引数も指定せずに collect -h コマンドを実行することによって確認できます。レジスタを指定する場合は、/ 文字が必要です。
標本収集間隔。カウンタオーバーフロー値を定義することによって設定されます。有効な値は次のとおりです。
デフォルトの頻度を使用して、100x/秒のデフォルトのクロックプロファイリングの頻度の分解能に一致させようとします。Solaris の場合、HWC レートは、負荷の大きいワークロードに合わせて実行時に変更できます。Linux の場合、レートは固定されたままのため、デフォルトは一部の raw カウンタには適した選択肢ではない場合があります。
間隔を on に比べて約 10 倍短い値に設定します。
間隔を on に比べて約 10 倍長い値に設定します。
間隔を 10 進数または 16 進数の形式で指定された特定の値に設定します。数値の設定には注意してください。特に、設定する間隔が短すぎると、アプリケーションや場合によってはシステム全体が過負荷になる可能性があります。大まかには、スレッドあたり 1000 イベント/秒を目標にしてください。
間隔は省略できます。その場合は、on の値が使用されます。間隔が省略された場合でも、その前にあるコンマは必要です (-h パラメータ内の最後のカウンタを除きます)。
raw カウンタの場合、hi、lo、on の値は推測ですが、特定のプログラムの適切な間隔を推測することは非常に困難です。raw カウンタに対して on/hi/lo を使用して、それぞれでイベントがスレッドあたり 100/1000/10/秒より速くなった場合は、間隔が調整されて、Oracle Solaris システムのより適切な最大値まで下げられます。
例: -h の使用法の有効ないくつかの例:
-h on
-h lo
-h hi
Enable the default counters with default, low, or
high rates, respectively
-h cycles,,insts,,+dcm
-h cycles -h insts -h +dcm
Both have the same meaning: three counters: cycles, insts
and dataspace-profiling of D-cache misses (SPARC only)
-h cycles~system=1
Count cycles in both user and system modes
-h 0xc0/0,10000003
On Nehalem, that is the equivalent to
-h inst_retired.any_p/0,10000003
-h の使用法の無効ないくつかの例:
-h cycles -h off Can't use off with any other -h arguments -h cycles,insts Missing comma, and "insts" does not parse as a number for <interval>
-h 引数がハードウェアカウンタの使用を指定していても、コマンドが指定された時点でハードウェアカウンタがほかのユーザーによって使用されている場合、collect コマンドはエラーを報告し、実験は実行されません。
-h 引数が指定されない場合、HW カウンタプロファイリングデータは収集されません。実験では、ハードウェアカウンタオーバーフロープロファイリングとクロックベースのプロファイリングの両方を指定できます。ハードウェアカウンタオーバーフロープロファイリングを指定しても、クロックプロファイリングは (デフォルトで有効になっていても) 無効になりません。
ハードウェアカウンタの詳細は、下記の「ハードウェアカウンタオーバーフロープロファイリング」のセクションを参照してください。
同期トレースデータを収集します。
イベントをトレースするための最小遅延しきい値は、option を使用して設定されます。option に使用できる値は次のとおりです。
同期遅延トレースを有効にし、実行時の調整によってしきい値を設定します。
on と同じです。
同期遅延トレースを無効にします。
n マイクロ秒のしきい値で同期遅延トレースを有効にします。n が 0 である場合は、すべてのイベントをトレースします。
同期遅延トレースを有効にし、すべての同期イベントをトレースします。
デフォルトでは、同期遅延トレースを無効にします。
Solaris では、次の関数がトレースされます。mutex_lock()、rw_rdlock()、rw_wrlock()、cond_wait()、cond_timedwait()、cond_reltimedwait()、thr_join()、sema_wait()、pthread_mutex_lock()、pthread_rwlock_rdlock()、pthread_rwlock_wrlock()、pthread_cond_wait()、pthread_cond_timedwait()、pthread_cond_reltimedwait_np()、pthread_join()、sem_wait()。
Linux では、次の関数がトレースされます。pthread_mutex_lock()、pthread_cond_wait()、pthread_cond_timedwait()、pthread_join()、sem_wait()。
Java プログラムの場合は、JVM マシン内のネイティブな同期呼び出しではなく、ユーザーコード内の Java モニターの同期イベントを記録します。
ヒープトレースデータを収集します。option に使用できる値は次のとおりです。
メモリー割り当てリクエストのトレースを有効にします。
メモリー割り当てリクエストのトレースを無効にします。
デフォルトでは、ヒープトレースを無効にします。
すべてのネイティブ呼び出しのヒープトレースイベントを記録します。mmap の呼び出しをメモリー割り当てとして扱います。
ヒーププロファイリングは、Java プログラムに対してはサポートされていません。これを指定すると、エラーとして扱われます。
ヒープトレースにより、非常に大きな実験が生成される可能性があることに注意してください。このような実験は、ロードや参照が非常に遅くなります。
I/O トレースデータを収集します。option に使用できる値は次のとおりです。
I/O 操作のトレースを有効にします。
I/O 操作のトレースを無効にします。
デフォルトでは、I/O 操作を無効にします。
I/O トレースにより、非常に大きな実験が生成される可能性があることに注意してください。このような実験は、ロードや参照が非常に遅くなります。
MPI 実験の収集を指定します。(下記の「MPI プロファイリング」を参照)。collect のターゲットは mpirun であるべきであり、またその引数は挿入された -- 引数でユーザーターゲット (つまり、mpirun によって実行されるプログラム) から分離されるべきです。この実験は通常どおりに名前が付けられ、「初期の実験」と呼ばれます。そのディレクトリには、ランクによって名前が付けられた、MPI プロセスごとのサブ実験が含まれます。collect とそのオプションを mpirun コマンド行の先頭に追加することによって実験を収集できるように、mpirun では常に -- 引数を使用することをお勧めします。
option に使用できる値は次のとおりです。
指定された MPI バージョンを前提にして、MPI 実験の収集を有効にします。認識された MPI のバージョンは、引数なしで collect を入力したとき、または -M で指定された認識されないバージョンに応答して出力されます。
MPI 実験の収集を無効にします。
デフォルトでは、MPI 実験の収集を無効にします。MPI 実験を有効にすると、-m (下記を参照) のデフォルト設定が on に変更されます。
MPI トレースデータを収集します。(下記の「MPI プロファイリング」を参照)。
option に使用できる値は次のとおりです。
MPI トレース情報を有効にします。
MPI トレース情報を無効にします。
デフォルトでは、MPI トレースを無効にします。ただし、-M フラグが有効になっている場合を除きます。その場合は、MPI トレースがデフォルトで有効になります。通常、MPI 実験は -M で収集され、MPI トレースのユーザー制御は必要ありません。MPI 実験は収集するが、MPI トレースデータを収集したくない場合は、次の明示的なフラグを使用できます。
-M MPI-version -m off
カウントデータを収集します。option に使用できる値は次のとおりです。
カウントデータを有効にします。
すべての命令が正確に 1 回実行されたという前提に基づいて、シミュレートされたカウントデータを有効にします。
カウントデータを無効にします。
デフォルトでは、カウントデータを無効にします。ほかの種類のデータについて、カウントデータを収集することはできません。カウントデータまたはシミュレートされたカウントデータでは、実行可能ファイルと、計測されて静的にリンクされたすべての共有オブジェクトがカウントされます。カウントデータでは (ただし、シミュレートされたカウントデータを除く)、動的にロードされた共有オブジェクトも計測されてカウントされます。
Solaris では、特別なコンパイルは不要ですが、コンパイルフラグ -p、-pg、-qp、-xpg、および -xlinkopt を使用したカウントオプションは互換性がありません。Linux では、カウントデータを収集するには実行可能ファイルを -annotate=yes フラグでコンパイルする必要があります。
カウントデータ計測のディレクトリを指定します。
ライブラリが実行可能ファイルにリンクされているか、 dlopen (3C) によってロードされるかにかかわらず、カウントデータの計測から除外するライブラリを指定します。複数の -N オプションを指定できます。
スレッドアナライザ用に、データ競合検出またはデッドロック検出のデータを収集します。
option に使用できる値は次のとおりです。
データの競合を検出するためのデータを収集します。
デッドロックおよび潜在的デッドロックを検出するためのデータを収集します。
データの競合、デッドロック、および潜在的デッドロックを検出するためのデータを収集します。race,deadlock としても指定できます。
データの競合、デッドロック、および潜在的デッドロックのデータ収集を無効にします。
データの競合を検出するためのデータを収集します (race と同じ)。
回復不可能なエラーが検出された場合は、ターゲットプロセスを終了します。
回復不可能なエラーが検出された場合は、ターゲットプロセスを終了してコアダンプを出力します。
回復不可能なエラーが検出された場合も、プロセスの続行を許可します。
デフォルトでは、スレッドアナライザのすべてのデータの収集を無効にします。
terminate、abort、および continue オプションは、どのデータ収集オプションにも追加できます。これらのオプションは、実際の (潜在的でない) デッドロックなどの回復不可能なエラーが発生した場合の動作を管理します。デフォルトの動作は terminate です。
スレッドアナライザのデータは、トレースデータとともに収集することはできませんが、クロックまたはハードウェアカウンタプロファイリングデータと組み合わせて収集できます。スレッドアナライザのデータはターゲットの実行速度を大幅に低下させるため、プロファイルをユーザーコードに適用しても意味がない可能性があります。
スレッドアナライザの実験は、analyzer または tha のどちらかで検査できます。後者はデフォルトのタブの単純なリストを表示しますが、それ以外は同じです。
データ競合検出を有効にするには、コンパイル時か、またはポストプロセッサを呼び出すことによって、実行可能ファイルを計測する必要があります。ターゲットが計測されず、かつそのライブラリリスト上のどの共有オブジェクトも計測されない場合は、警告が表示されますが、実験は実行されます。スレッドアナライザのその他のデータには計測は必要ありません。
詳細は、tha(1) のマニュアルページまたは『スレッドアナライザユーザーズガイド』を参照してください。
指定された間隔 (秒単位) で定期的な標本を収集します。プロセスからのデータ標本を記録し、特に、カーネルからのタイムスタンプと実行統計を含めます。interval に使用できる値は次のとおりです。
定期的な標本収集を無効にします。
デフォルトの標本収集間隔 (1 秒) で定期的な標本収集を有効にします。
n (秒単位) の標本収集間隔で定期的な標本収集を有効にします。n は正である必要があります。
デフォルトでは、定期的な標本収集を有効にします。
データ指定の引数が指定されていない場合は、デフォルトの分解能を使用して、クロックベースのプロファイリングデータを収集します。
クロックベースのプロファイリングが明示的に無効になっており、かつハードウェアカウンタオーバーフロープロファイリングまたは何らかの種類のトレースのどちらも有効になってない場合は、関数レベルのデータが収集されないという警告を表示したあと、ターゲットを実行してグローバルデータを記録します。
記録されるプロファイリングおよびトレースデータの量を sizeM バイトに制限します。この制限は、すべてのプロファイリングデータとトレースデータの合計に適用されますが、標本ポイントには適用されません。この制限値は概数にすぎないので、この値を超えることは可能です。この制限に達すると、プロファイリングおよびトレースデータは停止しますが、実験を開いたままにして、ターゲットプロセスが終了するまで標本を記録します。size に使用できる値は次のとおりです。
実験にサイズ制限を適用しません。
nM バイトの制限を適用します。n の値は正である (0 を超えている) 必要があります。
デフォルトでは、記録されるデータサイズに制限はありません。
子孫プロセスのデータを記録するかどうかを制御します。(どの -F 設定とも関係なく、常に親プロセスに関するデータが収集されます)。option に使用できる値は次のとおりです。
すべての子孫プロセスについて実験を記録します。
どの子孫プロセスについても実験を記録しません。
実行可能ファイル名 (a.out 名) が正規表現に一致する子孫プロセスについて実験を記録します。フルパスではなく、実行可能ファイルのベース名のみが使用されます。使用する <regex> に、シェルによって解釈される空白または文字が含まれている場合は、=<regex> 引数全体を必ず単一引用符で囲むようにしてください。
デフォルトでは、すべての子孫プロセスについて実験を記録します。詳細は、下記の「子孫プロセスの追尾」および「スクリプトのプロファイリング」のセクションを参照してください。
ターゲットプロセスによって使用されたロードオブジェクトをアーカイブするか、または記録された実験にコピーするかを制御します。option に使用できる値は次のとおりです。
ロードオブジェクト (ターゲット、およびターゲットが使用するすべての共有オブジェクト) を実験にコピーします。また、ロードオブジェクト内に存在しない Stab または DWARF 情報を含む .anc ファイルと .o ファイルもすべてコピーします。
-A on の場合と同様のロードオブジェクトのコピーに加えて、見つかったすべてのソースファイルと .anc ファイルを実験にコピーします。
-A on の場合と同様のロードオブジェクトのコピーに加えて、記録されたデータで参照されていて、見つかったすべてのソースファイルと .anc ファイルを実験にコピーします。
ロードオブジェクトまたはソースファイルを実験にコピーまたはアーカイブしません。
実験を別のマシンにコピーするか、または実験を別のマシンから読み取る場合は、-A on を指定します。それにより、消費されるディスク容量は増えますが、実験をほかのマシンで読み取ることができるようになります。
-A on では、ソースもオブジェクトファイル (.o) もコピーされないことに注意してください。実験が検査されるマシンからこれらのファイルに確実にアクセスでき、また実験が記録されたあとにこれらのファイルが変更または再構築されないようにすることはユーザーの責任です。
Archiving of experiment at collection time, especially for experiments with many descendant processes, can be very expensive. A better strategy is to collect the data with -A off, and then run er_archive (1) with the -s flag after the run is terminated.
-A のデフォルト設定は on です。
ターゲットが JVM マシンである場合の Java プロファイリングを制御します。option に使用できる値は次のとおりです。
JVM マシンのプロファイリングデータを記録し、Java HotSpot[TM] 仮想マシンでコンパイルされたメソッドを認識するほか、Java 呼び出しスタックも記録します。
Java プロファイリングデータを記録しません。
JVM のプロファイリングデータを記録し、<path> にインストールされた JVM を使用します。
下記の「Java プロファイリング」のセクションを参照してください。
ターゲットが JVM マシンである場合、プロファイリングデータを取得するには -j on を使用する必要があります。ターゲットがクラスまたは jar ファイルである場合、-j on オプションは必要ありません。64 ビットの JVM マシンを使用している場合は、そのパスをターゲットとして明示的に指定する必要があります。32 ビットの JVM マシンに -d64 オプションを使用しないでください。-j on オプションが指定されているが、ターゲットが JVM マシンでない場合は、無効な引数がターゲットに渡される可能性があります。また、データは記録されません。collect コマンドは、Java プロファイリングに指定された JVM マシンのバージョンを検証します。
プロファイルで使用するために JVM へ渡される追加引数を指定します。-J が指定された場合、Java プロファイリング (-j on) が有効になります。複数の引数が含まれている場合は、java_arg を引用符で囲む必要があります。これは、空白またはタブのどちらかで区切られた一連のトークンで構成されます。各トークンは、個別の引数として JVM に渡されます。JVM へのほとんどの引数は「-」文字で始まる必要があることに注意してください。
特定のシグナルがプロセスに配信された場合は常に、標本ポイントを記録します。
シグナルの選択の詳細は、下記の「データ収集とシグナル」のセクションを参照してください。
signal によるデータの記録を制御し、一時停止/再開シグナルと呼ばれます。特定のシグナルがプロセスに配信された場合は常に、一時停止状態 (データは記録されない) と再開状態 (データが記録される) を切り替えます。オプションの ,r フラグが指定されている場合は再開状態で起動し、それ以外の場合は一時停止状態で起動します。このオプションは、標本ポイントの記録には影響を与えません。
一時停止/再開シグナルの 1 つの使用法として、データを収集せずにターゲットを起動し、ターゲットが定常状態に到達できるようにしたあと、データを有効にする方法があります。
シグナルの選択の詳細は、下記の「データ収集とシグナル」のセクションを参照してください。
記録される実験の名前として experiment_name を使用します。experiment_name は、文字列 .er で終わる必要があります。そうでない場合は、エラーメッセージを出力し、実験は実行しません。
-o が指定されていない場合は、実験に stem.n.er という形式の名前を付けます。ここで、stem は文字列であり、n は数値です。-g でグループ名が指定されている場合は、stem を .erg 接尾辞の付かないグループ名に設定します。グループ名が指定されていない場合は、stem を文字列「test」に設定します。
MPI ジョブを実行するために使用されるいずれかのコマンド (mpirun など) から呼び出されたが、-M MPI-versions がなく、-o も指定されていない場合は、名前で使用される n の値をそのプロセスの MPI ランクを定義するために使用される環境変数から取得します。それ以外の場合、現在使用されている最も大きい整数値に 1 を加えた値を n に設定します。(下記の「MPI プロファイリング」を参照)。
名前が stem.n.er という形式で指定されておらず、かつ指定された名前が使用されている場合は、エラーメッセージを出力し、実験は実行しません。名前が stem.n.er という形式であり、かつ指定された名前が使用されている場合は、現在使用されている n の最大値より 1 大きい値に対応する名前で実験を記録します。名前が変更された場合は、警告を出力します。
directory_name ディレクトリ内に実験を配置します。ディレクトリが指定されていない場合は、現在の作業ディレクトリ内に実験を配置します。グループが指定されている場合は (下記の -g を参照)、そのグループファイルも -d で指定されたディレクトリに書き込まれます。
データ収集をもっとも軽くするには、データの配置先のディレクトリを指定するために使用される -d を使用して、ローカルファイルにデータを記録することが最適です。ただし、クラスタ上の MPI 実験の場合、すべてのデータが初期の実験に記録されるようにするには、すべてのプロセスが同じパスで初期の実験にアクセスできる必要があります。
待機時間の長いファイルシステムに書き込まれる実験では特に問題が発生し、標本データが収集される場合 (デフォルトの -S on) は特に、進捗が非常に遅くなることがあります。待ち時間の長い接続を経由して記録を行う必要がある場合には、標本データを無効にしてください。
実験グループ group_name に実験を追加します。group_name 文字列は、文字列 .erg で終わる必要があります。そうでない場合は、エラーを報告し、実験は実行しません。グループファイルの最初の行には、次の文字列が含まれている必要があります。
#analyzer experiment group
また、以降の各行は実験の名前です。
collect 自体のすべての出力を指定されたファイルのあとに付加しますが、生成されたターゲット、(-P 引数で呼び出された) dbx、(-c 引数で呼び出された) カウントデータの記録に関わるプロセスのいずれの出力もリダイレクトしません。file が /dev/null に設定されている場合は、あらゆるエラーメッセージを含む collect のすべての出力が抑制されます。
指定された期間だけデータを収集します。duration には、1 つの数値のあとに、分を指定する m か秒を指定する s (デフォルト)、または - 記号で区切られたこれらの 2 つの数値のいずれかを指定できます。1 つの数値が指定されている場合、データは実行の開始から指定された時間まで収集されます。2 つの数値が指定されている場合、データは最初の時間から 2 番目の時間まで収集されます。2 番目の時間が 0 である場合、データは実行の終了まで収集されます。0 以外の数値を 2 つ指定する場合、最初の数値は 2 番目の数値未満である必要があります。
dbx が、指定された PID のプロセスに接続し、プロセスからデータを収集し、そのスクリプトで dbx を起動するためのスクリプトを作成します。クロックまたは HW カウンタプロファイリングデータは指定できますが、トレースデータもカウントデータもサポートされません。詳細は、collector(1) のマニュアルページを参照してください。
プロセスに接続するとき、ディレクトリは collect -P を実行中のユーザーの umask を使用して作成されますが、実験は接続先のプロセスを実行するユーザーとして書き込まれます。接続を実行するユーザーが root で、umask がゼロでない場合、実験は失敗します。
ドライラン: ターゲットを実行しませんが、実行される実験のすべての詳細情報を出力します。-v を有効にします。
廃止。その趣旨のメッセージを出力して終了します。このオプションは、将来のリリースで削除される予定です。
現在のバージョンを出力します。それ以上の引数を検査せず、それ以上の処理も行いません。
現在のバージョンと、実行されている実験に関するより詳細な情報を出力します。
デバッガから接続できるように、exec システムコールの終了時にターゲットプロセスを停止されたままにします。collect コマンドは、プロセス PID を含むメッセージを出力します。
ターゲットが collect によって停止されたあと、そのターゲットにデバッガを接続するには、次の手順に従います。
collect -x コマンドによって出力されたメッセージからプロセスの PID を取得します。
デバッガを起動します
SIGPROF と、ハードウェアカウンタデータを収集することを選択した場合は Solaris では SIGEMT、Linux では SIGIO を無視するようにデバッガを構成します。
dbx の attach コマンドを使用してプロセスに接続します。
収集する実験のためのコレクタのパラメータを設定します。
collector enable コマンドを発行します。
ターゲットプロセスを実行できるように cont コマンドを発行します。
プロセスがデバッガの制御下で実行されると、コレクタは実験を記録します。
別の方法として、プロセスに接続し、collect -P PID コマンドを使用して実験を収集することもできます。
collect によって生成された初期プロセス (親プロセスと呼ばれます) からのデータは、常に収集されます。プロセスは、システムライブラリ関数 (fork、exec、system、etc のバリアントを含む) を呼び出すことによって子孫プロセスを作成できます。-F 引数が使用されている場合、コレクタは子孫プロセスのデータを収集できるため、親の実験の内部の子孫プロセスごとに新しい実験を開きます。これらの新しい実験には、次のように、その系統を使用した名前が付けられます。
作成者の実験名にアンダースコアが付加される。
fork を示す「f」か、または exec を含むその他の子孫を示す「x」のどちらかのコード文字が追加されます。Linux では、clone(2) によって生成された子孫に対して「C」が使用されます。
コード文字のあとに、子孫のインデックスである番号が追加されます。
系統のあとに、実験接尾辞である「.er」が付加されます。
たとえば、初期プロセスの実験名が「test.1.er」である場合、その 3 回目の fork の呼び出しで作成された子孫プロセスの実験は「test.1.er/_f3.er」です。その子孫プロセスが新しいイメージに対して exec を実行した場合、対応する実験名は「test.1.er/_f3_x1.er」です。
デフォルトの -F on が使用されている場合は、fork(2)、fork1(2)、fork(3F)、vfork(2)、および exec(2) とそのバリアントの呼び出しによって開始された子孫プロセスが追尾されます。vfork の呼び出しは、内部的に fork1 の呼び出しに置き換えられます。また、system(3C)、system(3F)、sh(3F)、popen(3C)、および同様の関数の呼び出しによって作成された子孫と、それに関連付けられた子孫プロセスも追尾されます。Linux では、デフォルトでは CLONE_VM フラグを付けないで clone() によって作成された子孫が追尾されます。CLONE_VM フラグで作成された子孫はプロセスではなくスレッドとして扱われ、-F 設定に関係なく常に追尾されます。
-F =<regex> 引数が使用されている場合は、名前がその正規表現に一致するすべての子孫が追尾されます。名前を照合する場合は、フルパスでもどの引数でもなく、実行可能ファイルのベース名のみが使用されます。
たとえば、親での system の最初の呼び出しからの最初の fork からの最初の exec の子孫プロセスに関するデータを取得するには、次のように実行します。
collect -F '=_x1_f1_x1'
exec のすべてのバリアントに関するデータを取得するが、fork については取得しないようにするには、次のように実行します。
collect -F '=.*_x[0-9]/*'
system("goodbye") ではなく system("echo hello") の呼び出しからデータを取得するには、次を使用します。
collect -F '=echo hello'
アナライザと er_print は、初期の実験が読み取られるときに子孫プロセスの実験を自動的に読み取り、その子孫プロセスの実験がデータ表示として選択されます。
表示するデータをコマンド行から明確に選択するには、er_print またはアナライザにパス名を明示的に指定します。指定されるパスには、初期の実験の名前と、親ディレクトリの内部にある派生実験の名前が含まれている必要があります。
たとえば、test.1.er 実験の 3 回目の fork のデータを表示するには、次のように実行します。
er_print test.1.er/_f3.er analyzer test.1.er/_f3.er
対象とする派生実験の明示的な名前を含む実験グループファイルを準備できます。
アナライザで子孫プロセスを検査するには、初期の実験をロードし、「表示」>「データをフィルタ」を選択します。アナライザに、初期の実験だけがオンになった実験のリストが表示されます。初期の実験をオフにし、対象とする派生実験をオンにします。
デフォルトでは、collect で、そのターゲットが ELF 実行可能ファイルである必要はなくなりました。collect がスクリプト上で呼び出された場合、そのスクリプトを実行するために起動されたプログラムとすべての子孫プロセスに関するデータが収集されます。特定のプロセスに関するデータのみを収集するには、-F フラグを使用して、追尾する実行可能ファイルの名前を指定します。
たとえば、スクリプト foo.sh をプロファイルするが、主に実行可能ファイル bar からデータを収集するには、次のコマンドを使用します。
collect -F =bar foo.sh
スクリプトを実行するために起動された親プロセスと、そのスクリプトから生成されたすべての bar プロセスに関するデータが収集されますが、その他のプロセスに関するデータは収集されません。
Java プロファイリングは、.class または .jar ファイルを実行している JVM マシン上のパフォーマンス実験の収集で構成されます。可能な場合は、Java モデル内とマシンモデル内の両方の呼び出しスタックが収集されます。
データは、「ユーザー」、「上級」、または「マシン」に設定された表示モードで表示できます。「ユーザー」モードでは、各メソッドが名前によって示され、インタプリタされたメソッドと HotSpot でコンパイルされたメソッドのデータがまとめて集計されます。また、非ユーザー Java スレッドのデータは抑止されます。「上級」モードでは、HotSpot でコンパイルされたメソッドがインタプリタされたメソッドから分離され、非ユーザー Java スレッドは抑止されません。マシンモードでは、解釈された Java メソッドのデータが、解釈を実行している JVM マシンと対比して表示されます。これに対して、Java HotSpot 仮想マシンでコンパイルされたメソッドのデータは、指定されたメソッドに対して報告されます。すべてのスレッドが表示されます。3 つのすべてのモードで、データは、Java ターゲットから呼び出された非 OpenMP のすべての C、C++、または Fortran コードに対する通常の方法で報告されます。このようなコードは、Java ネイティブメソッドに対応しています。アナライザと er_print ユーティリティーは、「ユーザー」、「上級」、「マシン」の各表示モードを切り替えることができ、デフォルトは「ユーザー」です。
クロックベースのプロファイリングとハードウェアカウンタオーバーフロープロファイリングがサポートされています。同期トレースは、Java モニターの呼び出しと、ネイティブコードからの同期呼び出しに関するデータのみを収集します。JVM 内の内部の同期呼び出しに関するデータは収集しません。
ヒープトレースは、Java に対してはサポートされておらず、指定された場合はエラーを生成します。
一部の Java コードは、jar ファイル内に共有オブジェクトが含まれています。これらの共有オブジェクトは、アプリケーションが実行されると一時ディレクトリに抽出され、そのアプリケーションが終了すると削除されます。共有オブジェクト名は実験のマップファイル内に記録されますが、jar ファイル名は記録されません。そのような実験を読み取るには、jar ファイルをリストした <tt>addpath</tt> ディレクティブを <tt>.er.rc</tt> ファイルに追加するか、アナライザ GUI からパスを追加するか、<tt>er_print</tt> で <tt>addpath</tt> コマンドを使用します。実験がアーカイブされる時点で <tt>addpath</tt> ディレクティブが <tt>.er.rc</tt> ファイル内にある場合、共有オブジェクトがアーカイブされます。
collect は、引数リストに java のターゲット名を挿入するとき、最初に JDK_HOME、次に JAVA_PATH の順序で、環境変数に java ターゲットへのパスが存在するかどうかを検査します。このうち設定されている最初の環境変数について、結果として得られるターゲットが ELF 実行可能ファイルとして検証されます。存在しない場合、collect は失敗し、使用された環境変数と試行されたフルパス名を示すエラーが表示されます。
これらの環境変数のどちらも設定されていない場合、collect コマンドは、PATH によって設定されているバージョンを使用します。PATH に java が存在しない場合は、/usr/java/bin/java のシステムのデフォルトが試行されます。
一部のアプリケーションは純粋な Java ではなく、dlopen を呼び出して libjvm.so をロードしたあと、そこに呼び出すことによって JVM を起動する C または C++ アプリケーションです。コレクタは、Java プロファイリングが自動的に有効になるように環境変数を設定します。
通常、collect コマンドでは、初期のライブラリリストに記載されているか、明示的に dlopen でロードされるかにかかわらず、ターゲットのアドレス空間内のすべての共有オブジェクトのデータが収集されます。ただし、状況によっては、一部の共有オブジェクトがプロファイルされない場合もあります。
このようなシナリオの 1 つとして、ターゲットプログラムが遅延ロードで呼び出される場合があります。この場合、ライブラリは起動時にロードされず、dlopen の明示的な呼び出しによってもロードされないため、共有オブジェクト名が実験に含まれず、そのオブジェクトからのすべての PC が <Unknown> 関数にマップされます。これを回避するには、LD_BIND_NOW を設定して、ライブラリが起動時に強制的にロードされるようにします。
このようなシナリオのもう 1 つの例として、実行可能ファイルが -B direct リンクオプションで構築される場合があります。この場合、オブジェクトは dlopen の動的リンカーのエントリポイントへの明確な呼び出しによって動的にロードされるため、libcollector 割り込みがバイパスされます。共有オブジェクト名が実験に含まれず、そのオブジェクトからのすべての PC が <Unknown> 関数にマップされます。これを回避するには、-B direct を使用しないようします。
シグナルは、クロックプロファイリングとハードウェアカウンタオーバーフロープロファイリングの両方に使用されます。SIGPROF は、すべての実験のデータ収集で使用されます。シグナルを生成する期間は、収集されるデータによって異なります。SIGEMT (Solaris) または SIGIO (Linux) は、ハードウェアカウンタオーバーフロープロファイリングに使用されます。オーバーフローの間隔は、プロファイリングのユーザーパラメータによって異なります。プロファイリングシグナルを使用または操作する何らかのユーザーコードが、データ収集の妨げになる可能性があります。コレクタは、そのシグナルハンドラをプロファイルシグナル用にインストールする場合、シグナルを配信するシステムコールの処理が中断されないようにするためのフラグを設定します。この設定により、プロファイリングシグナルをほかの目的に使用しているターゲットプログラムの動作が変更される可能性があります。
コレクタは、そのシグナルハンドラをプロファイルシグナル用にインストールする場合、ターゲットが独自のシグナルハンドラをインストールしているかどうかを記憶します。コレクタはまた、一部のシグナル処理ルーチンに割り込み、ユーザーがこれらのシグナル用にシグナルハンドラをインストールできないようにします。コレクタは、実験の開始時にユーザーハンドラを置き換える場合と同様に、そのユーザーのハンドラを保存します。
プロファイリングシグナルは、カーネル内のプロファイルタイマーまたはハードウェアカウンタオーバーフロー処理コードによって、あるいは kill (2) 、 sigsend (2) 、 tkill (2) , tgkill(2)、 _lwp_kill (2) の各システムコール、 raise (3C) 、 sigqueue (3C) の各ライブラリコール、または kill (1) コマンドに応答して配信されます。コレクタが起点を区別できるように、シグナルコードがシグナルとともに配信されます。シグナルコードは、プロファイリングのために配信される場合はコレクタによって処理されます。プロファイリングのために配信されない場合は、ターゲットのシグナルハンドラに配信されます。
コレクタが dbx の下で実行されているときに、配信されたプロファイリングシグナルのシグナルコードが破壊されたり、プロファイルシグナルがシステムまたはライブラリコールあるいはコマンドから生成されたかのように扱われたりする場合があります。その場合は、ユーザーのハンドラに誤って配信されます。ユーザーハンドラが SIG_DFL に設定されていた場合は、プロセスが失敗してコアダンプが生成されます。
コレクタがターゲットプロセスへの接続のあとに呼び出された場合、コレクタはそのシグナルハンドラをインストールしますが、シグナル処理ルーチンに割り込むことはできません。これらのユーザーコードが接続のあとにシグナルハンドラをインストールした場合は、コレクタのシグナルハンドラがオーバーライドされ、データは失われます。
いずれかのプロファイリングシグナルを含むあらゆるシグナルによって、システムコールが途中で終了することがあり、この動作を処理するためのプログラムを作成する必要があります。libcollector がデータ収集用のシグナルハンドラをインストールするとき、再起動可能なシステムコールの再起動を指定しますが、 sleep (3C) などのようにエラーを報告せずに早く返されるものもあります。
シグナルは、ユーザーが標本シグナル (-l) または一時停止/再開シグナル (-y) として指定できます。この使用には SIGUSR1 または SIGUSR2 が推奨されますが、ターゲットによって使用されない任意のシグナルを使用できます。
プロファイリングシグナルは、プロセスがそれ以外ではそのシグナルを使用しない場合に使用できますが、ほかのシグナルが使用できない場合にのみ使用するようにしてください。コレクタは、一部のシグナル処理ルーチンに割り込み、ユーザーがこれらのシグナル用にシグナルハンドラをインストールできないようにします。コレクタは、実験の開始時にユーザーハンドラを置き換える場合と同様に、そのユーザーのハンドラを保存します。
コレクタがターゲットプロセスへの接続のあとに呼び出され、ユーザーコードが標本または一時停止/再開シグナル用にシグナルハンドラをインストールした場合、それらのシグナルは指定されたとおりに動作しなくなります。
OpenMP プログラムのデータ収集では、Java プログラムの場合と同様に、3 つのどの表示モードでも表示できるデータを収集します。「ユーザー」モードでは、スレーブスレッドが実際にマスタースレッドから複製され、呼び出しスタックがマスタースレッドからのスレーブスレッドに対応しているかのように表示されます。OpenMP 実行時コード (libmtsk.so) から来た、呼び出しスタック内のフレームは抑制されます。「上級」ユーザーモードでは、マスタースレッドとスレーブスレッドが異なる方法で表示され、コンパイラで生成された明示的な関数が表示され、OpenMP 実行時コード (libmtsk.so) からのフレームは抑制されます。「マシン」モードでは、実際のネイティブなスタックが表示されます。
ユーザーモードでは、実行時ライブラリがいくつかの状態のいずれかにある場合は常に、呼び出しスタックのリーフ関数としてさまざまな擬似関数が導入されます。これらの関数は、<OMP-overhead>、<OMP-idle>、<OMP-reduction>、<OMP-implicit_barrier>、<OMP-explicit_barrier>、<OMP-lock_wait>、<OMP-critical_section_wait>、および <OMP-ordered_section_wait> です。
クロックプロファイリング実験のデータに、次の 3 つのクロックプロファイリングメトリックが追加されています。
OpenMP Work (ompwork) OpenMP Wait (ompwait) Master Thread Time (masterthread)
OpenMP ワークは、OpenMP ランタイムがコードを実行中と見なしている場合にカウントされます。これには、プロセスがユーザー CPU 時間を消費している時間が含まれますが、プロセスがシステム CPU 時間を消費したり、ページフォルトを待機したり、CPU を待機したりしている時間などが含まれる場合もあります。そのため、OpenMP ワークはユーザー CPU 時間を超える場合があります。OpenMP 待ちは、OpenMP ランタイムがプロセスを待機中と見なしている場合に累積されます。OpenMP 待ちには、ビジー待ち (スピン待ち) のためのユーザー CPU 時間が含まれる場合がありますが、スリープ待ちのためのほかの待ち時間も含まれます。
マスタースレッド時間は、マスタースレッドで費やされた合計時間です。これは Solaris 実験からのみ使用できます。これは時計時間に対応します。
包括的メトリックは、デフォルトで表示されます。排他的メトリックは、デフォルトでは表示されません。これらの 2 つのメトリックの合計がスレッド合計時間メトリックに等しくなります。これらのメトリックは、すべてのクロックおよびハードウェアカウンタプロファイリング実験で追加されます。
プログラムの実行中にすべての並列領域エントリの情報を収集すると、非常にコストが高くなる場合があります。そのコストを抑制するには、環境変数 SP_COLLECTOR_NO_OMP を設定します。SP_COLLECTOR_NO_OMP を設定すると、プログラムの膨張は大幅に減少しますが、この変数が設定されていない場合に表示される、スレーブスレッドから呼び出し元に、そして最終的に main() に伝播されるデータは表示されなくなります。
このリリースでは、OpenMP 3.0 の新しいコレクタがデフォルトで有効になっています。このコレクタは、明示的なタスクを使用するプログラムのプロファイルを実行できます。以前のバージョンのコンパイラで構築されたプログラムは、libmtsk.so のパッチ適用済みバージョンが利用可能な場合にのみ、新しいコレクタでプロファイル可能です。これがインストールされていない場合は、環境変数 SP_COLLECTOR_OLDOMP を設定することによって、古いコレクタを使用するようにデータ収集を切り替えることができます。
OpenMP プロファイリング機能は、Oracle Solaris Studio コンパイラのランタイムに依存するため、Oracle Solaris Studio コンパイラでコンパイルされたアプリケーションでのみ使用可能なことに注意してください。GNU でコンパイルされたコードでは、マシンレベルの呼び出しスタックのみが表示されます。
メモリー領域プロファイルは、キャッシュミスなどのメモリー関連イベントが、キャッシュライン、メモリーバンク、ページなどの、マシンの物理的な構造に対して報告されるプロファイルです。
データ領域プロファイルは、これらのメモリー関連イベントが、メモリー関連イベントが発生した命令だけではなく、そのイベントの原因となる参照を行なったデータ構造に対して報告されるプロファイルです。データ領域プロファイリングは、Oracle Solaris を実行している SPARC システム上でのみ使用できます。Oracle Solaris または Linux を実行している x86 システム上ではまだ使用できません。
メモリー領域またはデータ領域のいずれかのプロファイリングの場合、収集されるデータは、メモリーベースのカウンタを使用するハードウェアカウンタである必要があります。正確なカウンタの場合は、SPARC または x86 Oracle Solaris プラットフォームのどちらでも、デフォルトではメモリー領域およびデータ領域データが収集されます。
データ領域プロファイリングをサポートするには、実行可能ファイルを -xhwcprof フラグでコンパイルするようにしてください。このフラグは C、C++、および Fortran コンパイラでのコンパイルに適用できますが、SPARC[R] プラットフォームでのみ意味があります。このフラグはほかのプラットフォームでは無視されます。実行可能ファイルが -xhwcprof でコンパイルされない場合、er_print の data_layout、data_single、および data_objects コマンドではデータが表示されません。メモリー領域プロファイリングでは、正確なカウンタのために -xhwcprof は必要ありません。
高精度割り込みを備えたマシンでは、メモリー領域プロファイリングのコンパイルに -xhwcprof フラグは必要ありません。そのようなマシンでも、データ領域プロファイリングにはフラグが必要です。
収集されるデータについて、er_print ユーティリティーでは、メモリーオブジェクト関連のさまざまなコマンドだけでなく、data_objects、data_single、data_layout の 3 つの追加コマンドを使用できます。詳細は、er_print(1) のマニュアルページを参照してください。
さらに、パフォーマンスアナライザには、データ領域プロファイリング関係の 2 つのデータビュー (「データオブジェクト」と「データレイアウト」のラベル付き) と、「メモリーオブジェクト」に関連するビューのセットが含まれます。
collect コマンドを MPI プロファイリングに使用すると、構成 MPI プロセスからのデータの収集を管理したり、MPI トレースデータを収集したり、データを MPI プロセスごとに「サブ実験」を持つ 1 つの「初期の」実験に整理したりできます。
collect コマンドを MPI で使用するには、単純に、MPI ジョブを起動するコマンドとその引数の前に目的の collect コマンドとその引数を置きます (-- 引数を挿入して mpirun の引数の終了を示していると仮定します)。たとえば、SMP マシン上で、
% mpirun -np 16 -- a.out 3 5
は、次のコマンドに置き換えることができます。
% collect -M OMPT mpirun -np 16 -- a.out 3 5
このコマンドは、16 個の各 MPI プロセス上で MPI トレース実験を実行し、それらをすべて実験の通常の命名規則で指定された MPI 実験内に収集します。ここでは、Oracle Message Passing Toolkit (以前の Sun HPC ClusterTools) バージョンの MPI を使用することを前提にしています。
最初の collect プロセスは、mpirun コマンドの形式を変更して、個々の各 MPI プロセス上で適切な引数で collect を実行するように指定します。
collect が mpirun の引数をターゲットとその引数から分離できるように、MPI プロファイリングでは、ターゲット名の直前に (mpirun 自体ではオプションである) -- 引数が必要なことに注意してください。-- 引数が指定されていない場合、collect はエラーメッセージを出力し、実験は実行されません。
さらに、リモートの collect がそのターゲットを見つけることができるように、collect によって mpirun の引数に -x PATH 引数が追加されます。環境内のいずれかの環境変数が「VT_」または「SP_COLLECTOR_」で始まっている場合、それらの各環境変数は -x フラグとともにリモートの collect に渡されます。
MIMD MPI の実行は、各「:」のあとに (新しいターゲットとそのためのローカルの mpirun の引数を示す)「--」引数が存在する必要があるという同様の要件の下にサポートされます。-- 引数が指定されていない場合、collect はエラーメッセージを出力し、実験は実行されません。
Oracle Message Passing Toolkit (Sun HPC ClusterTools) の一部のバージョンには、MPI の状態のプロファイリングのための機能があります。このようなバージョンの MPI で実行された MPI 実験に関するクロックプロファイリングデータが収集された場合は、次の 2 つの追加メトリックを表示できます。
MPI Work (mpiwork) MPI Wait (mpiwwait)
MPI ワークは、プロセスがリクエストやメッセージの処理など、実行中の MPI ランタイムの内部にある場合に累積されます。MPI 待ちは、プロセスが MPI ランタイムの内部にあるが、イベント、バッファー、またはメッセージを待機している場合に累積されます。
Solaris システムでは、MPI 待ちは、MPI ライブラリが待機時にスリープしているかスピンしているかにかかわらず累積されます。Linux システムでは、MPI 待ちは、MPI ライブラリが待機時にスピンしている場合に累積されます。MPI ライブラリが待機時にスリープ (CPU を生成) している場合は累積されず、実際の待機時間に比べて少なくカウントされます。
アナライザでは、MPI トレースデータが収集された場合、「MPI タイムライン」と「MPI チャート」の 2 つの追加のタブが表示されます。
mpirun を使用して、MPI プロセス上で明示的な collect コマンドを生成する技法は MPI トレースデータの収集にはサポートされなくなったため、使用しないでください。その他のすべてのタイプのデータには、引き続き使用できます。
MPI プロファイリングは、オープンソースの VampirTrace 5.5.3 リリースに基づいています。これは、いくつかの VampirTrace 環境変数と、呼び出しスタックをデータ内に記録するかどうかを制御する新しい環境変数である VT_STACKS を認識します。これらの変数の意味については、VampirTrace 5.5.3 のドキュメントを参照してください。
環境変数 VT_BUFFER_SIZE のデフォルト値によって MPI API トレースコレクタの内部バッファーが 64M バイトに制限され、VT_MAX_FLUSHES のデフォルト値によって、バッファーがフラッシュされる回数が 1 に制限されます。これらの制限に達したあとに記録されるイベントは、トレースファイルには書き込まれなくなります。環境変数は、並列アプリケーションのすべてのプロセスに適用されます。つまり、n 個のプロセスを含むアプリケーションは通常、シリアルアプリケーションの n 倍のサイズのトレースファイルを作成します。
この制限を削除し、アプリケーションの完全なトレースを取得するには、VT_MAX_FLUSHES を 0 に設定します。この設定を行うと、MPI API トレースコレクタは、バッファーがいっぱいになるたびにバッファーをディスクにフラッシュします。バッファーのサイズを変更するには、環境変数 VT_BUFFER_SIZE を使用します。この変数の最適な値は、トレースされるアプリケーションによって異なります。小さい値を設定すると、アプリケーションで利用できるメモリーが増えますが、MPI API トレースコレクタによってバッファーのフラッシュが頻繁に引き起こされます。このようなバッファーのフラッシュによって、アプリケーションの動作が大幅に変化する可能性があります。これに対して、2G などの大きな値を設定すると、MPI API トレースコレクタによるバッファーのフラッシュが最小限に抑えられますが、アプリケーションで使用できるメモリーは少なくなります。バッファーとアプリケーションデータを保持するための十分なメモリーが利用できない場合、この設定によりアプリケーションの一部がディスクにスワップされ、アプリケーションの動作が大きく変化する可能性があります。
別の重要な変数として、さまざまなエラーメッセージやステータスメッセージを有効にする VT_VERBOSE があります。問題が発生した場合は、これを 2 以上に設定することをお勧めします。
通常、MPI トレース出力データは mpirun ターゲットの終了時に後処理されます。処理されたデータファイルは実験に書き込まれ、後処理時間情報が実験ヘッダーに書き込まれます。MPI トレースが明示的に無効になっている場合、MPI 後処理は実行されません。
後処理に失敗した場合は、エラーが報告され、MPI タブや MPI トレースメトリックは使用できなくなります。
mpirun ターゲットが実際に MPI を起動しない場合も、実験は引き続き記録されますが、MPI トレースデータは生成されません。実験によって MPI 後処理のエラーが報告され、MPI タブや MPI トレースメトリックは使用できなくなります。
環境変数 VT_UNIFY が「0」に設定されている場合、後処理ルーチン er_vtunify および er_mpipp は collect によっては実行されません。これらのルーチンは、実験で er_print または analyzer のどちらかがはじめて起動されたときに実行されます。
ppgsz コマンドで collect コマンドを実行し、-F on フラグを指定することによって、collect コマンドを ppgsz とともに使用できます。初期の実験は ppgsz 実行可能ファイル上に存在し、考慮の対象外です。現在のパスに 32 ビットバージョンの ppgsz が見つかり、64 ビットプロセスをサポートするシステム上で実験が実行されている場合、collect コマンドは、最初にその 64 ビットバージョンで exec 関数を実行して _x1.er を作成します。この実行可能ファイルを fork し、_x1_f1.er を作成します。子孫プロセスは、指定されたターゲットに対して、最初に現在のパス上の最初のディレクトリ内で、次に 2 番目のディレクトリ内で exec 関数を実行しようとし、以降も同様に、いずれかの exec 関数が成功するまで実行を試行します。たとえば、3 回目の試行が成功した場合、最初の 2 つの派生実験には _x1_f1_x1.er および _x1_f1_x2.er という名前が付けられますが、これはどちらも完全に空です。ターゲット上の実験は、成功した 3 回目の exec によるもので、_x1_f1_x3.er という名前が付けられ、親の実験の下に格納されます。これは、test.1.er/_x1_f1_x3.er に対してアナライザまたは er_print ユーティリティーを起動することによって直接処理できます。
64 ビットの ppgsz が初期プロセスの実行であるか、または 32 ビットの ppgsz が 32 ビットカーネル上で起動された場合は、パスのプロパティーが上記の例と同じであると仮定して、実際のターゲット上で exec を実行する fork の子孫のデータは _f1.er 内に存在し、実際のターゲットの実験は _f1_x3.er 内に存在します。
上記の「子孫プロセスの追尾」のセクションを参照してください。ハードウェアカウンタの詳細は、下記の「ハードウェアカウンタオーバーフロープロファイリング」のセクションを参照してください。
collect コマンドは、共有ライブラリ libcollector.so を、特定のトレースデータ収集のための追加の共有ライブラリとともにターゲットのアドレス空間 (LD_PRELOAD) に挿入することによって動作します。これらの共有ライブラリは、実験を構成するファイルを書き込みます。
collect が、setuid や setgid を呼び出すか、または setuid や setgid を呼び出す子孫プロセスを作成する実行可能ファイル上で呼び出された場合は、いくつかの問題が発生する可能性があります。実験を実行しているユーザーが root でない場合は、共有ライブラリが信頼できるディレクトリ内にインストールされていないため、収集は失敗します。これを回避するには、root として実験を実行するか、または crle(1) を使用してアクセス権を付与します。もちろん、セキュリティーバリアーを迂回する場合はユーザーが十分な注意を払い、各自のリスクで行うようにしてください。
さらに、collect コマンドを実行しているユーザーの umask を設定することにより、そのユーザー、exec で実行されているプログラムの setuid/setgid 属性によって設定されたすべてのユーザーまたはグループ、およびそのプログラム自体の設定先であるすべてのユーザーまたはグループに書き込み権限を許可する必要があります。マスクが正しく設定されていない場合、一部のファイルが実験に対して書き込まれず、実験が処理不能になることがあります。ログファイルが書き込み可能な場合は、ユーザーが実験を処理しようとすると、エラーが表示されます。
あるユーザーとして、別のユーザーによって所有されているプロセスに接続する場合、接続先のプロセスを所有しているユーザーによる書き込みを許可するには、umask を設定する必要があることに注意してください。
ターゲット自体が UID または GID を設定する何らかのシステムコールを発行した場合や、自身の umask を変更してから fork を実行するか、ほかの何らかのプロセスに対して exec を実行した場合、または crle を使用して実行時リンカーによる共有オブジェクトの検索方法が構成されている場合は、ほかの問題が発生する可能性があります。
実効 GID を変更するターゲット上で実験が root として開始された場合、実験の終了時に実行される er_archive プロセスが失敗します。これは、このプロセスには「信頼できる」にマークされていない共有ライブラリが必要なためです。その場合は、実験の終了直後に、実験が記録されたマシン上で er_archive (または er_print かアナライザ) を手動で明示的に実行できます。
プロファイリングデータ、トレースデータ、標本データの 3 種類のデータが収集されます。プロファイリングおよびトレースで記録されるデータパケットには、各 LWP の呼び出しスタック、LWP、スレッド、CPU ID のほか、一部のイベント固有のデータが含まれます。標本収集で記録されるデータパケットには、実行統計などのグローバルデータが含まれますが、プログラム固有のデータやイベント固有のデータは含まれません。すべてのデータパケットにはタイムスタンプが含まれます。
各データの種類では、そのデータから派生したメトリックについて、名前と、実験を検査する metrics コマンドでユーザーが使用する文字列の両方を説明します。
クロックベースのプロファイリングで記録されるイベント固有のデータは、アカウンティングマイクロステートごとのカウントの配列です。マイクロステート配列は、所定の頻度でシステムによって増分され、プロファイリングシグナルが処理されるときにコレクタによって記録されます。
クロックベースのプロファイリングはさまざまな頻度で実行できますが、この頻度は、プロファイリングタイマーに使用されているクロック分解能の倍数である必要があります。高分解能プロファイリングをサポートしていないオペレーティングシステムのマシン上で高分解能プロファイリングを実行しようとすると、このコマンドは警告メッセージを出力し、サポートされているもっとも高い分解能を使用します。同様に、システムによってサポートされている分解能の倍数でないカスタム設定は、その分解能のもっとも近い 0 以外の倍数に切り下げられ、警告メッセージが出力されます。
クロックベースのプロファイリングデータは、次のメトリックに変換されます。
Total Thread Time (total) Total CPU Time (totalcpu) User CPU Time (user) System CPU Time (system) Trap CPU Time (trap) User Lock Time (lock) Data Page Fault Time (datapfault) Text Page Fault Time (textpfault) Kernel Page Fault Time (kernelpfault) Stopped Time (stop) Wait CPU Time (wait) Sleep Time (sleep)
マルチスレッドアプリケーション上の実験では、すべての時間がプロセス内のすべてのスレッドにわたって集計されます。スレッド合計時間は、プロセス内のスレッドの平均数を掛けて、実際の経過時間に加算されます。
クロックベースのプロファイリングが OpenMP プログラム上で実行されている場合は、次の 3 つの追加メトリック
OpenMP Work (ompwork) OpenMP Wait (ompwait) Master Thread Time (masterthread)
が提供されます。Solaris では、OpenMP ワークは、作業が並列に実行されている場合に累積されます。OpenMP 待機は、OpenMP ランタイムが同期化を待機している場合に蓄積し、待機が CPU 時間かスリーピングを使用しているか、または作業は並行してなされるがスレッドが CPU 上でスケジュールされていない場合に蓄積します。マスタースレッド時間は、マスタースレッド内の時間のみを表します。
Linux では、OpenMP ワークおよび OpenMP 待ちは、プロセスがユーザーモードまたはシステムモードのどちらかでアクティブである場合にのみ累積されます。OpenMP でビジー待ちを実行するように指定していないかぎり、Linux 上の OpenMP 待ちは役に立ちません。マスタースレッド時間は、Linux では提供されません。
クロックベースのプロファイリングが MPI プログラム上で実行されている場合は、Oracle Message Passing Toolkit (Sun HPC ClusterTools) リリース 8.1 以降で実行すると、次の 2 つの追加メトリック
MPI Work (mpiwork) MPI Wait (mpiwait)
が提供されます。Solaris では、MPI ワークは、MPI ランタイムがアクティブである場合に累積されます。MPI 待ちは、MPI ランタイムがメッセージの送信または受信を待機している場合や、MPI ランタイムがアクティブであるが、スレッドが CPU 上で実行されていない場合に累積されます。
Linux では、MPI 作業および MPI 待機は、プロセスがユーザーモードまたはシステムモードでアクティブである場合にのみ累積されます。MPI でビジー待ちを実行するように指定していないかぎり、Linux 上の MPI 待ちは役に立ちません。
ハードウェアカウンタオーバーフロープロファイリングは、オーバーフローシグナルが処理された時点でのハードウェアカウンタによってカウントされたイベントの数を記録します。
使用可能なカウンタは、特定のプロセッサチップやオペレーティングシステムによって異なります。ほかのどの引数も指定せずに collect -h コマンドを実行すると、プロセッサ、および使用可能なハードウェアカウンタの数が、そのプロセッサのすべてのカウンタのリストとデフォルトのハードウェアカウンタセットとともに説明されます。一般的な名称として別名が設定されたカウンタがリストの最初に含まれ、raw ハードウェアカウンタのリストが続きます。既知のカウンタのリストが出力されたあとに、そのチップのリファレンスマニュアルの名前と、そのチップに対して定義されているデフォルトのカウンタセットが出力されます。
パフォーマンスカウンタサブシステムまたは collect のどちらも特定のチップ上のカウンタの名前を認識していない場合、これらの表は空になります。ただしその場合でも、前述のように、カウンタを数値で指定できます。出力行の形式は次のとおりです。
プロファイリングに使用可能な別名を付けた HW カウンタ:
cycles[/{0|1}],<interval> ('CPU Cycles', alias for Cycle_cnt; CPU-cycles)
insts[/{0|1}],<interval> ('Instructions Executed', alias for Instr_cnt; events)
dcrm[/1],<interval> ('D$ Read Misses', alias for DC_rd_miss; load events)
...
プロファイリングに使用可能な raw HW カウンタ:
Cycle_cnt[/{0|1}],<interval> (CPU-cycles)
Instr_cnt[/{0|1}],<interval> (events)
DC_rd[/0],<interval> (load events)
SI_snoop[/0],<interval> (not-program-related events)
...
別名を付けたカウンタの出力の最初の行で、最初のフィールド「cycles」は、-h 引数で使用できるカウンタ名を示しています。そのあとに、そのカウンタに使用できるレジスタの指定が続きます。メトリック名は「CPU Cycles」で、raw ハードウェアカウンタ名は「Cycle_cnt」です。最後のフィールド「CPU-cycles」は、カウントされている単位のタイプを指定します。情報のタイプには、最大 2 つのワードを指定できます。タイプ情報の 2 番目または唯一のワードには、「CPU-cycles」または「events」のどちらかを指定できます。この値は、そのカウンタを使用して時間ベースのメトリックを提供できる場合は CPU-cycles、それ以外の場合は events です。
上に示されている別名を付けたカウンタの出力の 2 番目の出力行では、行の最後に「CPU-cycles」ではなく「events」が存在し、それがイベントのカウントであり、時間には変換できないことを示しています。
上に示されている 3 番目の出力行では、行の最後にタイプ情報の 2 つのワード「load events」が存在します。タイプ情報の最初のワードは、「load」、「store」、「load-store」、「not-program-related」のいずれかの値を持つことができます。これらのタイプ値のうち最初の 3 つは、そのカウンタがメモリー関連であり、collect -h コマンドで使用するときにカウンタ名の前に「+」記号を付けることができることを示します。「+」記号は、オーバーフローしたカウンタ上のイベントの原因になった正確な命令と仮想アドレスの検索を試みるためのデータ収集のリクエストを示します。
一部のチップでは、カウンタ割り込みが正確であるため、「+」符号は必要ありません。このようなカウンタは、イベントタイプのあとの「(precise)」というワードで示されます。
「not-program-related」の値は、そのカウンタがほかの何らかのプログラムによって開始されたイベント (CPU から CPU へのキャッシュスヌープなど) を取得することを示します。プロファイリングにカウンタを使用すると、警告が生成され、プロファイリングで呼び出しスタックが記録されません。ただし、「collector_not_program_related」と呼ばれる擬似関数で費やされている時間を表示します。スレッド ID と LWP ID は記録されますが、意味がありません。
raw ハードウェアカウンタリスト内の各行には、cputrack(1) で使用された内部カウンタ名、そのカウンタを使用できるレジスタ番号、デフォルトのオーバーフロー値、および CPU-cycles または events のどちらかのカウンタ単位が含まれています。
ハードウェアカウンタデータから報告されるメトリックには、使用されるカウンタによって名前が付けられます。カウンタがサイクル数で計測される場合、データは時間に変換され、イベントで計測する場合、データはイベント数として報告されます。サイクルベースのカウンタをイベントとして表示するユーザーオプションもあります。
「cycles」と「insts」の 2 つの特定のカウンタが収集される場合、「CPI」と「IPC」という 2 つのメトリックが使用可能になり、これらはそれぞれ「命令当たりのサイクル数」と「サイクル当たりの命令数」を意味します。これらは常に比率として表示され、時間、カウント、あるいはパーセントで示されません。CPI 値が高いか IPC 値が低ければ、マシン内でのコードの実行が非効率であることを示し、逆に CPI 値が低いか IPC 値が高ければ、パイプライン内で実行中のコードの効率がよいことを示します。
例:
例 1: 上記のサンプル出力に示されている別名を付けたカウンタ情報を使用すると、次のコマンド
collect -h cycles,3600003
を使用して、3600003 が選択されている CPU サイクルのプロファイリングで、3.6 GHz システム上でスレッドあたり約 1000 イベント/秒のピークイベントレートを生成することができます。(生成するイベントレートが高すぎると、最終的にはプロファイリングを試みるパフォーマンスが不安定になります。Solaris システムの場合は、数値のオーバーフロー間隔ではなく、on/high/low を使用できます。)
例 2:
AMD Opteron マシン上でほかのどの引数も指定せずに collect -h コマンドを実行すると、次のような raw ハードウェアカウンタ出力が生成されます。
FP_dispatched_fpu_ops[/{0|1|2|3}],<interval> (events)
FP_cycles_no_fpu_ops_retired[/{0|1|2|3}],<interval> (CPU-cycles)
...
上記の raw ハードウェアカウンタ出力を使用すると、次のコマンド
collect -h FP_dispatched_fpu_ops~umask=0x3/2,10007
により、10007 回のイベントごとに 1 回の取得のレートで浮動小数点加算および乗算操作を追跡できるようになります。(有効な属性値の詳細は、プロセッサのドキュメントを参照してください)。「/2」の値は、ハードウェアのレジスタ 2 を使用してデータを取得するように指定します。
サポートされている Solaris システム、および 2.6.32 以降のバージョン番号の Linux カーネルを実行している Linux のサポートされているバージョンには、すでにインストールされているハードウェアカウンタオーバーフロープロファイリングのための必要な OS サポートがあります。
2.6.32 より前のカーネルを含むサポートされている Linux システムは、perfctr フレームワークを使用しています。必要な perfctr パッチをシステムにインストールすることはユーザーの責任です。このパッチは、Web で「perfctr パッチ」を検索することによって見つけることができます。インストール方法の指示は、パッチのダウンロード場所にある tar ファイルに含まれています。コレクタは、ユーザーレベルの libperfctr.so ライブラリを LD_LIBRARY_PATH を使用して検索したあと、32 ビットバージョンの場合は /usr/local/lib、/usr/lib/、および /lib/ で、また 64 ビットバージョンの場合は /usr/local/lib64 /usr/lib64/、および /lib64/ で検索します。
同期遅延トレースは、呼び出しでのリアルタイム遅延が指定されたしきい値を超える、さまざまなスレッド同期ルーチンのすべての呼び出しを記録します。このデータパケットには、同期ルーチンの開始と終了のタイムスタンプ、スレッド ID、およびリクエストが開始された時点での LWP ID が含まれます。(スレッドからの同期リクエストは 1 つの LWP 上で開始できますが、別の LWP 上で完了します)。
同期遅延トレースデータは、次のメトリックに変換されます。
Synchronization Wait Time (sync) Synchronization Delay Events (syncn)
ヒープトレースは、リクエストされたブロックサイズによる malloc、free、realloc、memalign、および valloc のすべての呼び出しとそのアドレス、さらに realloc の場合は以前のアドレスを記録します。calloc の呼び出しは、Oracle Solaris では記録されますが、Linux では記録されません。
ヒープトレースデータは、次のメトリックに変換されます。
Allocations (heapalloccnt) Bytes Allocated (heapallocbytes) Leaks (heapleakcnt) Bytes Leaked (heapleakbytes)
リークは、解放されない割り当てとして定義されます。長さ 0 のブロックが割り当てられた場合は、0 バイトが割り当てられた割り当てとしてカウントされます。長さ 0 のブロックが解放されない場合は、0 バイトがリークされたリークとしてカウントされます。
ヒープトレース実験は非常に大きくなる場合があり、処理も遅くなることがあります。
IO トレースは、標準 IO ルーチンとすべての IO システムコールのすべての呼び出しを記録します。
IO トレースデータは、次のメトリックに変換されます。
Bytes Read (ioreadbytes) Read Count (ioreadcnt) Read Time (ioreadtime) Bytes Written (iowritebytes) Write Count (iowritecnt) Write Time (iowritetime) Other IO Count (ioothrcnt) Other IO Time (ioothertime) IO Error Count (ioerrornt) IO Error Time (ioerrortime)
MPI トレースは、完了に非常に長い時間がかかる可能性のある関数のための MPI ライブラリの呼び出しを記録します。MPI トレースは、オープンソースの VampirTrace コードを使用して実装されます。
MPI トレースデータは、次のメトリックに変換されます。
MPI Time (mpitime) MPI Sends (mpisendcnt) MPI Bytes Sent (mpisendbytes) MPI Receives (mpirecvcnt) MPI Bytes Received (mpirecvbytes) Other MPI Events (mpiothercnt)
MPI 時間は、MPI 関数で費やされたスレッド合計時間です。MPI 状態の時間も収集される場合、MPI_Init および MPI_Finalize 以外のすべての MPI 関数については、MPI 作業時間と MPI 待機時間の合計が MPI 作業時間にほぼ等しくなるはずです。Linux では、MPI 待ちおよび MPI ワークがユーザーとシステムの CPU 時間に基づいているのに対して、MPI 時間は実際の時間に基づいているため、これらの数値は一致しません。
MPI 受信バイト数は、すべてのメッセージで実際に受信したバイト数をカウントします。MPI 送信バイト数は、すべてのメッセージで実際に送信したバイト数をカウントします。MPI 送信数は送信したメッセージの数をカウントし、MPI 受信数は受信したメッセージの数をカウントします。MPI_Sendrecv は、送信と受信の両方をカウントします。その他の MPI イベントは、送信でも受信でもないトレース内のイベントをカウントします。
カウントデータは、実行可能ファイルを計測し、各命令が実行された回数をカウントすることによって記録されます。また、関数での最初の命令が実行された回数をカウントし、これを関数実行カウントと呼びます。SPARC システムの場合のみ、分岐の遅延スロット内の命令が無効化された回数もカウントされます。
カウントデータは、次のメトリックに変換されます。
Bit Func Count (bit_fcount) Bit Inst Exec (bit_instx) Bit Inst Annul (bit_annul) -- SPARC only
データ競合検出データは、競合を構成する競合アクセスイベントのペアで構成されます。これらのイベントが結合されて競合が構成され、2 つのアクセスの呼び出しスタックが同じである競合が競合グループにマージされます。
データ競合検出データは、次のメトリックに変換されます。
Race Accesses (raccess)
デッドロック検出データは、ロックが競合するスレッドのペアで構成されます。
デッドロック検出データは、次のメトリックに変換されます。
Deadlocks (deadlocks)
標本収集とは、実行のタイムラインに沿ってマーカーを生成するプロセスを指します。各標本ポイントでは、実行統計が記録されます。標本ポイントで記録されたすべてのデータがプログラムに対してグローバルであり、関数レベルのメトリックにはマップされません。
標本は常に、プロセスの開始時と終了時に取得されます。デフォルトでは、または 0 以外の -S 引数が指定された場合、標本は指定された間隔で定期的に取得されます。さらに、libcollector(3) の API を使用して標本を取得することもできます。
各標本ポイントで記録されたデータは、カーネルからのマイクロステートアカウンティング情報、およびカーネル内で保持されているその他のさまざまな統計情報で構成されます。
パフォーマンスアナライザのほとんどのバイナリは、それらのバイナリを含むインストールからの共有ライブラリの検索に依存しています。ユーザーは、ツールの別のインストールのライブラリディレクトリを含むように LD_LIBRARY_PATH を設定してはいけません。LD_LIBRARY_PATH が別のインストールに設定されていると、バイナリの実行に失敗する可能性があります。
コレクタは、最大 32K 個のユーザースレッドをサポートできます。これを超えるスレッドからのデータは破棄され、コレクタのエラーが生成されます。より多くのスレッドをサポートするには、環境変数 SP_COLLECTOR_NUMTHREADS をより大きな数に設定します。
デフォルトでは、コレクタは 256 フレームの深さのスタックを収集します。より深いスタックをサポートするには、環境変数 SP_COLLECTOR_STACKBUFSZ をより大きな数に設定します。
コレクタは、クロックベースのプロファイリングのための SIGPROF シグナルの使用、およびハードウェアカウンタオーバーフロープロファイリングのための SIGEMT (Solaris) または SIGIO (Linux) の使用をターゲットプログラムによる中断から保護するために、一部のシグナル処理ルーチンに割り込みます。上記の「データ収集とシグナル」のセクションを参照してください。
コレクタは、クロックベースのプロファイリングが有効になっている場合にターゲットプログラムがプロファイリングタイマーを使用できないようにするために、 setitimer (2) に割り込みます。
コレクタは、コレクタでパフォーマンスデータを収集している間にアプリケーションがハードウェアカウンタを使用できないようにするために、ハードウェアカウンタライブラリ libcpc.so 内の関数に割り込みます。割り込まれた関数は、-1 の値を返します。
データ領域プロファイリングは、Linux OS を実行しているシステムや、Solaris OS を実行している x86 ベースシステム上では使用できません。
このリリースでは、定期的な標本の収集から得られたデータは、Linux OS を実行しているシステム上では信頼できません。
このリリースでは、RedHat Enterprise Linux OS を実行しているシステム上でマルチスレッドアプリケーションをプロファイリングした場合、データの広範な相違が観察されます。
cpustat がカウンタを制御し、ユーザープロセスでカウンタを使用できないようにしているため、cpustat が実行されているシステム上ではハードウェアカウンタオーバーフロープロファイリングを実行できません。
Java プロファイリングには、Java[TM] 2 SDK (JDK) 7 Update 11 以降の JDK 7 が必要です。
collect は、-xprofile=tcov フラグでコンパイルされた実行可能ファイルでは使用できません。
setuid 属性を使用するために作成された子孫プロセスや、動的にリンクされていない実行可能ファイルの exec 呼び出しで作成された子孫プロセスに関するデータは収集されません。さらに、以降の子孫プロセスによって、破壊された実験や読み取れない実験が生成される可能性があります。これを回避するには、生成されるすべてのプロセスが動的にリンクされ、また setuid 属性を持つこともないようにします。
vfork(2) を呼び出すアプリケーションでは、これらの呼び出しが fork1(2) の呼び出しに置き換えられます。
Linux 5 システムではカウントデータ (collect -c) は収集できず、どの Linux システムでも 32 ビットバイナリのカウントデータはまったく収集できません。
analyzer (1) , collector (1) , dbx (1) , er_archive (1) , er_cp (1) , er_export (1) , er_mv (1) , er_print (1) , er_rm (1) , tha (1) , libcollector (3)
パフォーマンスアナライザマニュアル