コレクタが収集するデータの内容

コレクタは、次のいくつかの方法を使用して、さまざまな種類のデータを収集します。

• プロファイルデータの収集は、一定の間隔でプロファイルイベントを記録することによって行います。間隔は、システム時間を使用して取得した時間間隔、または特定のタイプのハードウェアイベントの数です。指定の間隔に達すると、シグナルがシステムに送られ、次の機会にデータが記録されます。

• トレースデータは、さまざまなシステム関数やライブラリ関数の呼び出しをインターセプトし、その呼び出しに関するデータを記録できるように、それらの関数にラッパー関数で割り込むことによって収集されます。

• 大域データの収集は、さまざまなシステムルーチンを呼び出して情報を取得することによって行います。大域データパケットのことを標本と呼びます。

• 関数と命令のカウントデータは、実行可能ファイルと、その実行可能ファイルが静的にリンクしている、計測されるすべての共有オブジェクトに対して収集されます。関数と命令が実行された回数が記録されます。

• スレッド分析データは、スレッドアナライザをサポートするために収集されます。

プロファイルデータとトレースデータの両方が特定のイベントに関する情報を含んでおり、いずれのデータの種類もパフォーマンスメトリックに変換されます。大域データはメトリックに変換されませんが、プログラムの実行を複数のタイムセグメントに分割するために使用できるマーカーを提供します。大域データは、タイムセグメントにおけるプログラム実行の概要を示します。

それぞれのプロファイルイベントやトレースイベントで収集されたデータパケットには、次の情報が含まれます。

• データ識別用のヘッダー

• 高分解能のタイムスタンプ

• スレッド ID

• 軽量プロセス (LWP) ID

• プロセッサ (CPU) ID (オペレーティングシステムから提供できる場合)

• 呼び出しスタックのコピー。Java プログラムの場合、マシン呼び出しスタックと Java 呼び出しスタックの 2 つの呼び出しスタックが記録されます。

• OpenMP プログラムの場合、現在の並行領域の識別子と、OpenMP の状態も収集されます。

スレッドと軽量プロセスについての詳細は、第 6 章パフォーマンスアナライザとそのデータについてを参照してください。

こうした共通の情報のほかに、各イベントに固有のデータパケットには、データの種類に固有の情報が含まれます。

このあとの各項では、これらのデータの種類とその使用方法について説明します。

• 「クロックデータ」

• 「ハードウェアカウンタオーバーフローのプロファイルデータ」

• 「同期待ちトレースデータ」

• 「ヒープトレース (メモリー割り当て) データ」

• 「MPI トレースデータ」

• 「大域 (標本収集) データ」

クロックデータ

時間ベースのプロファイル時に収集されるデータは、オペレーティングシステムが提供するメトリックによって異なります。

Oracle Solaris でのクロックベースのプロファイリング

Oracle Solaris での時間ベースのプロファイリングでは、各スレッドの状態が定期的な時間間隔で格納されます。この時間間隔は、プロファイル間隔と呼ばれます。この情報は整数の配列に格納されます。その配列の 1 つの要素は、カーネルによって維持される 10 個のマイクロアカウンティングの各状態に使用されます。収集されたデータは、各状態で消費された、プロファイル間隔の分解能を持つ時間値に、パフォーマンスアナライザによって変換されます。デフォルトのプロファイル間隔は、約 10 ミリ秒 (10 ms) です。コレクタは、約 1 ミリ秒の高分解能プロファイル間隔と、約 100 ミリ秒の低分解能プロファイル間隔を提供し、オペレーティングシステムで許されれば任意の間隔が許可されます。ほかの引数を指定せずに collect -h コマンドを実行すると、このコマンドが実行されるシステム上で許容可能な範囲と分解能が出力されます。

次の表に、時間ベースのデータから計算されるメトリックスの定義を示します。

表 2-1 Solaris タイミングメトリック

マルチスレッドの実験では、時計時間以外の時間がすべてのスレッドにわたって集計されます。定義された時計時間は、MPMD (multiple-program multiple-data) ターゲットには意味がありません。

タイミングメトリックは、プログラムがいくつかのカテゴリで時間を費やした部分を示し、プログラムのパフォーマンス向上に役立てることができます。

• ユーザー CPU 時間が大きいということは、その場所で、プログラムが仕事の大半を行なっていることを示します。この情報は、アルゴリズムを再設計することによって特に有益となる可能性があるプログラム部分を見つけるのに使用できます。

• システム CPU 時間が大きいということは、プログラムがシステムルーチンに対する呼び出しで多くの時間を使用していることを示します。

• CPU 待ち時間が大きいということは、使用可能な CPU 以上に実行可能なスレッドが多いか、ほかのプロセスが CPU を使用していることを示します。

• ユーザーロック時間が大きいということは、要求対象のロックをスレッドが取得できないことを示します。

• テキストページフォルト時間が大きいということは、リンカーによって指定されたコードが、多数の呼び出しまたは分岐で新しいページの読み込みが発生するようなメモリー上の配置になることを意味します。

• データページフォルト時間が大きいということは、データへのアクセスによって新しいページの読み込みが発生していること示します。この問題は、プログラムのデータ構造またはアルゴリズムを変更することによって解決できます。

Linux での時間ベースのプロファイリング

Linux オペレーティングシステムでは、ユーザー CPU 時間が使用できる唯一のメトリックです。報告される合計 CPU 使用時間は正確ですが、アナライザは、実際にシステム CPU 時間である時間の割合を Oracle Solaris の場合ほど正確に判定できないことがあります。アナライザは、データが軽量プロセス (LWP) に対するものであるかのように情報を表示しますが、実際には Linux 上に LWP は存在せず、表示される LWP ID は実際にはスレッド ID です。

MPI プログラム対応の時間ベースのプロファイル

時間プロファイリングデータは、Oracle Message Passing Toolkit (以前の Sun HPC ClusterTools) で実行される MPI 実験で収集できます。Oracle Message Passing Toolkit はバージョン 8.1 またはそれ以降である必要があります。

Oracle Message Passing Toolkit は、Oracle Solaris 11 リリースの一部として入手可能になりました。システムにインストールされている場合は、/usr/openmpi にあります。まだ Oracle Solaris 11 システムにインストールされていない場合、システムにパッケージリポジトリが構成されていれば、コマンド pkg search openmpi を使用してこのパッケージを検索できます。Oracle Solaris 11 でのソフトウェアのインストールの詳細は、Oracle Solaris 11 ドキュメントライブラリのマニュアル『Oracle Solaris 11 ソフトウェアパッケージの追加および更新』を参照してください。

MPI 実験で時間プロファイリングデータを収集すると、次の 2 つのメトリックスが追加されます。

• MPI 作業: 要求やメッセージの処理など、プロセスが MPI ランタイム実行作業の内部にある場合に蓄積されます。

• MPI 待機: プロセスが MPI ランタイムの内部にあり、イベント、バッファー、またはメッセージを待機している場合に蓄積されます。

Oracle Solaris では、MPI 作業は、作業が直列または並列に実行されている場合に累積されます。MPI 待機は、MPI ランタイムが同期化を待機している間に蓄積され、待機が CPU 時間ないしスリーピングのいずれかを使用しているか、または作業が並列実行中であるがスレッドは CPU 上にスケジュールされていない場合に、蓄積されます。

Linux では、MPI 作業および MPI 待機は、プロセスがユーザーモードまたはシステムモードでアクティブである場合にのみ累積されます。MPI がビジーウェイトを行う必要があるものとして指定しないかぎり、Linux での MPI 待機は有用ではありません。

mpirun (Open MPI) 1.3.4r22104-ct8.2.1-b09d-r70

OpenMP プログラム対応の時間ベースのプロファイル

時間ベースのプロファイルが OpenMP プログラムで実行される場合は、OpenMP 作業および OpenMP 待機という 2 つの追加メトリックスが提供されます。

Oracle Solaris では、OpenMP 作業は、作業が直列または並列に実行されている場合に累積されます。OpenMP 待機は、OpenMP ランタイムが同期化を待機している場合に蓄積し、待機が CPU 時間かスリーピングを使用しているか、または作業は並行してなされるがスレッドが CPU 上でスケジュールされていない場合に蓄積します。

Linux オペレーティングシステムでは、OpenMP 作業および OpenMP 待機は、プロセスがユーザーモードまたはシステムモードでアクティブである場合にのみ累積されます。OpenMP でビジーウェイトを行う必要があるものとして指定しないかぎり、Linux での OpenMP は有用ではありません。

OpenMP プログラムのデータは、3 つの表示モードのいずれかで表示できます。「ユーザー」モードでは、スレーブスレッドが実際にマスタースレッドから複製され、呼び出しスタックがマスタースレッドからのスレーブスレッドに対応しているかのように表示されます。呼び出しスタック内にある、OpenMP 実行時コード (libmtsk.so) から来たフレームは抑制されます。「上級」ユーザーモードでは、マスタースレッドとスレーブスレッドが異なる方法で表示され、コンパイラで生成された明示的な関数が表示され、OpenMP 実行時コード (libmtsk.so) からのフレームは抑制されます。「マシン」モードでは、実際のネイティブなスタックが表示されます。

Oracle Solaris カーネルに対する時間ベースのプロファイリング

er_kernel ユーティリティーは、Oracle Solaris カーネルに関する時間ベースのプロファイルデータを収集できます。

er_kernel ユーティリティーはカーネルプロファイルデータを取り込み、そのデータをアナライザの実験として、ユーザープログラム上で collect ユーティリティーによって作成された実験と同じ形式で記録します。この実験は、er_print ユーティリティーまたはパフォーマンスアナライザによって処理できます。カーネルの実験は、関数データ、呼び出し元と呼び出し先のデータ、命令レベルのデータ、およびタイムラインを示すことができますが、ほとんどの Oracle Solaris モジュールには行番号テーブルが含まれていないため、ソース行データを示すことはできません。

詳細は、第 9 章カーネルプロファイリングを参照してください。

ハードウェアカウンタオーバーフローのプロファイルデータ

ハードウェアカウンタは、キャッシュミス、キャッシュストールサイクル、浮動小数点演算、分岐予測ミス、CPU サイクル、および実行対象命令といったイベントの追跡に使用されます。ハードウェアカウンタオーバーフロープロファイルでは、スレッドが実行されている CPU の指定されたハードウェアカウンタがオーバーフローしたときに、コレクタによってプロファイルパケットが記録されます。この場合、そのカウンタはリセットされ、カウントを続行します。プロファイルパケットには、オーバーフロー値とカウンタタイプが入っています。

さまざまなプロセッサチップファミリが、2 ~ 18 個の同時ハードウェアカウンタレジスタをサポートしています。コレクタは、複数のレジスタ上でデータを収集できます。コレクタでは、レジスタごとに、オーバーフローを監視するカウンタの種類を選択したり、カウンタのオーバーフロー値を設定したりすることができます。ハードウェアカウンタには、任意のレジスタを使用できるものと、特定のレジスタしか使用できないものがあります。このことは、1 つの実験であらゆるハードウェアカウンタの組み合わせを選択できるわけではないことを意味します。

また、ハードウェアカウンタオーバーフロープロファイルは、er_kernel ユーティリティーを使用してカーネルに対して実行することもできます。詳細は、第 9 章カーネルプロファイリングを参照してください。

パフォーマンスアナライザは、ハードウェアカウンタのオーバーフロープロファイルデータをカウントメトリックに変換します。循環型のカウンタの場合、報告されるメトリックは時間に変換されます。非循環型のカウンタの場合は、イベントの発生回数になります。複数の CPU を搭載したマシンの場合、メトリックの変換に使用されるクロック周波数が個々の CPU のクロック周波数の調和平均となります。プロセッサのタイプごとに専用のハードウェアカウンタセットがあり、またハードウェアカウンタの数が多いため、ハードウェアカウンタメトリックはここに記載していません。次の項で、どのような種類のハードウェアカウンタがあるかについて調べる方法を説明します。

ハードウェアカウンタの用途の 1 つは、CPU に出入りする情報フローに伴う問題を診断することです。たとえば、キャッシュミス回数が多いということは、プログラムを再構成してデータまたはテキストの局所性を改善するか、キャッシュの再利用を増やすことによってプログラムのパフォーマンスを改善できることを意味します。

ハードウェアカウンタはほかのカウンタと関連する場合があります。たとえば、分岐予測ミスが発生すると、間違った命令が命令キャッシュに読み込まれ、これらの命令を正しい命令と置換しなければならなくなるため、分岐予測ミスと命令キャッシュミスが関連付けられることがよくあります。置換により、命令キャッシュミス、命令変換ルックアサイドバッファー (ITLB) ミス、またはページフォルトが発生する可能性があります。

ハードウェアカウンタのオーバーフローは、イベントを発生させて対応するイベントのカウンタをオーバーフローにした命令のあとに、1 つ以上の命令で実現される傾向があります。これは「滑り止め」と呼ばれ、カウンタオーバーフローのプロファイルを解釈しにくくする可能性があります。原因となる命令を正確に識別するためのハードウェアサポートがないと、候補の原因となる命令の適切なバックトラッキング検索が行われる場合があります。

このようなバックトラッキングがサポートされていて、収集中に指定されると、ハードウェアカウンタプロファイルパケットにはさらに、ハードウェアカウンタイベントに適した候補のメモリー参照命令の PC (プログラムカウンタ) と EA (有効アドレス) が含まれます。解析中の以降の処理は、候補のイベント PC と EA を有効にするのに必要です。このメモリー参照イベントに関する追加情報により、データ空間プロファイリングと呼ばれるさまざまなデータ指向解析が容易になります。バックトラッキングは、Oracle Solaris オペレーティングシステムを実行している SPARC ベースのプラットフォームでのみサポートされます。

一部の SPARC チップでは、カウンタ割り込みが正確であるため、バックトラッキングは必要ありません。このようなカウンタは、イベントタイプのあとの precise というワードで示されます。

メモリーに関連した正確なカウンタの前に + 記号を付加すると、メモリー領域プロファイリングが有効になり、どのプログラム行やメモリーアドレスがメモリー関連のプログラム遅延の原因になっているかを判定するに役立ちます。メモリー領域プロファイリングの詳細は、「データ領域プロファイリングとメモリー領域プロファイリング」を参照してください。

候補のイベント PC および EA のバックトラッキングと記録は時間プロファイリングにも指定できますが、データの解釈が困難になることがあります。ハードウェアカウンタに対するバックトラッキングの方が信頼性は高くなります。

ハードウェアカウンタリスト

ハードウェアカウンタはプロセッサ固有であるため、どのカウンタを利用できるかは、使用しているプロセッサによって異なります。パフォーマンスツールには、よく使われると考えられるいくつかのカウンタの別名が用意されています。コレクタからいずれかの特定のシステム上で使用できるハードウェアカウンタの一覧を取得するには、ほかの引数を指定せずに collect -h をそのシステムの端末ウィンドウに入力します。プロセッサとシステムがハードウェアカウンタプロファイリングをサポートしている場合、collect -h コマンドは、ハードウェアカウンタに関する情報を含む 2 つのリストを出力します。最初のリストには一般的な名称に別名が設定されたハードウェアカウンタが含まれ、2 番目のリストには raw ハードウェアカウンタが含まれます。パフォーマンスカウンタサブシステムも collect コマンドも特定システムのカウンタの名前を知らない場合、各リストは空になります。ただしほとんどの場合、カウンタは数値で指定できます。

次に、カウンタリストに含まれるエントリの表示例を示します。別名が設定されたカウンタがリストの最初に表示され、続いて raw ハードウェアカウンタリストが表示されます。この例の出力における各行は、印刷用の形式になっています。

Aliased HW counters available for profiling:
cycles[/{0|1|2|3}],31599989 (`CPU Cycles', alias for Cycles_user; CPU-cycles)
insts[/{0|1|2|3}],31599989 (`Instructions Executed', alias for Instr_all; events)
loads[/{0|1|2|3}],9999991 (`Load Instructions', alias for Instr_ld; 
      precise load-store events)
stores[/{0|1|2|3}],1000003 (`Store Instructions', alias for Instr_st; 
      precise load-store events)
dcm[/{0|1|2|3}],1000003 (`L1 D-cache Misses', alias for DC_miss_nospec; 
      precise load-store events)
...
Raw HW counters available for profiling:
...
Cycles_user[/{0|1|2|3}],1000003 (CPU-cycles)
Instr_all[/{0|1|2|3}],1000003 (events)
Instr_ld[/{0|1|2|3}],1000003 (precise load-store events)
Instr_st[/{0|1|2|3}],1000003 (precise load-store events)
DC_miss_nospec[/{0|1|2|3}],1000003 (precise load-store events)

別名が設定されたハードウェアカウンタリストの形式

別名が設定されたハードウェアカウンタリストでは、最初のフィールド (たとえば、cycles) は、collect コマンドの -h counter... 引数で使用できる別名を示します。この別名は、 er_print コマンド内で使用する識別子でもあります。

2 つ目のフィールドには、そのカウンタに使用可能なレジスタの一覧 (たとえば、[/{0|1|2|3}]) が表示されます。

3 番目のフィールドは、たとえば 9999991 など、カウンタのデフォルトのオーバーフロー値です。別名が設定されたカウンタの場合は、合理的なサンプルレートを提供するためにデフォルト値が選択されています。実際のレートは、かなり変化するため、デフォルト以外の値を指定する必要がある場合もあります。

4 番目のフィールドは、括弧で囲まれ、タイプ情報を含んでいます。これは、簡単な説明 (たとえば、CPU Cycles)、raw ハードウェアカウンタ名 (たとえば、Cycles_user)、およびカウントされている単位の種類 (たとえば、CPU-cycles) を示します。

種類情報フィールド内の可能性のあるエントリには次のものがあります。

• precise - 命令によってイベントカウンタがオーバーフローすると、カウンタ割り込みが正確に発生します。collect -h コマンド内の load-store イベントカウンタの名前の前に + 記号を付加すると (たとえば、+dcm)、正確なカウンタが、プロファイリング専用にコンパイルされなかった通常のバイナリ上でメモリー領域プロファイリングを実行できます。

• load、store、または load-store のいずれかである場合、そのカウンタはメモリーに関連したものです。collect -h コマンド内のカウンタ名に + 記号を付加すると (たとえば、+dcrm)、イベントの原因になった正確な命令と仮想アドレスの検索を要求できます。+ 記号を使用すると、データ領域プロファイリングも有効になります。詳細は、「「データオブジェクト」タブ」、「「データレイアウト」タブ」、および 「メモリーオブジェクトのタブ」を参照してください。

• not-program-related である場合、カウンタはほかのプログラムによって開始されたイベント、たとえば CPU 対 CPU のキャッシュスヌープなどを取り込みます。プロファイリングにカウンタを使用すると、警告が生成され、プロファイリングで呼び出しスタックが記録されません。

タイプ情報の最後のワードまたは唯一のワードが、

• CPU-cycles である場合は、そのカウンタを使用して時間ベースのメトリックを提供できます。そのようなカウンタについて報告されるメトリックは、デフォルトでは包括的時間および排他的時間へ変換されますが、イベントカウントとして表示することもできます。

• events である場合、メトリックは包括的および排他的イベントカウントであり、時間へ変換できません。

この例の別名が設定されたハードウェアカウンタリストでは、タイプ情報に 1 ワードが含まれており、最初のカウンタの場合は CPU-cycles で、2 番目のカウンタの場合は、events となっています。3 番目のカウンタでは、タイプ情報に load-store events という 2 つのワードが含まれています。

raw ハードウェアカウンタリストの形式

raw ハードウェアカウンタリストに含まれる情報は、別名設定されたハードウェアカウンタリストに含まれる情報のサブセットです。raw ハードウェアカウンタリスト内の各行には、cputrack(1) で使用された内部カウンタ名、そのカウンタを使用できるレジスタ番号、デフォルトのオーバーフロー値、タイプ情報、および CPU-cycles または events のどちらかのカウンタ単位が含まれています。

カウンタがプログラムの実行に関連のないイベントを測定する場合、タイプ情報の最初のワードは not-program-related になります。そのようなカウンタの場合、プロファイリングで呼び出しスタックが記録されませんが、その代わりに、擬似関数 collector_not_program_related で使用された時間が示されます。スレッドと LWP ID は記録されますが、意味がありません。

raw カウンタのデフォルトのオーバーフロー値は 1000003 です。この値はほとんどの raw カウンタで最適でないため、raw カウンタを指定する際にオーバーフロー値を指定する必要があります。

同期待ちトレースデータ

マルチスレッドプログラムでは、たとえば、1 つのスレッドによってデータがロックされていると、別のスレッドがそのアクセス待ちになることがあります。これらのイベントは同期遅延イベントと呼ばれ、Solaris または pthread のスレッド関数の呼び出しをトレースすることによって収集されます。同期遅延イベントを収集して記録するプロセスを同期待ちトレースと言います。また、ロック待ちに費やされる時間を待ち時間と言います。

ただし、イベントが記録されるのは、その待ち時間がしきい値 (ミリ秒単位) を超えた場合だけです。しきい値 0 は、待ち時間に関係なく、あらゆる同期遅延イベントをトレースすることを意味します。デフォルトでは、同期遅延なしにスレッドライブラリを呼び出す測定試験を実施して、しきい値を決定します。こうして決定された場合、しきい値は、それらの呼び出しの平均時間に任意の係数 (現在は 6) を乗算して得られた値です。この方法によって、待ち時間の原因が本当の遅延ではなく、呼び出しそのものにあるイベントが記録されないようになります。この結果として、同期イベント数がかなり過小評価される可能性がありますが、データ量は大幅に少なくなります。

同期トレースは Java プログラムに対してはサポートされていません。

同期待ちトレースデータは、次のメトリックスに変換されます。

表 2-2 同期待ちトレースメトリック

この情報から、関数またはロードオブジェクトが頻繁にブロックされるかどうか、または同期ルーチンを呼び出したときの待ち時間が異常に長くなっているかどうかを調べることができます。同期待ち時間が大きいということは、スレッド間の競合が発生していることを示します。競合は、アルゴリズムの変更、具体的には、ロックする必要があるデータだけがスレッドごとにロックされるように、ロックを構成し直すことで減らすことができます。

ヒープトレース (メモリー割り当て) データ

正しく管理されていないメモリー割り当て関数やメモリー割り当て解除関数を呼び出すと、データの使い方の効率が低下し、プログラムパフォーマンスが低下する可能性があります。ヒープトレースでは、C 標準ライブラリメモリー割り当て関数 malloc、realloc、valloc、memalign、および割り当て解除関数 free で割り込み処理を行うことによって、コレクタはメモリーの割り当てと割り当て解除の要求をトレースします。mmap への呼び出しはメモリー割り当てとして扱われ、これによって Java メモリー割り当てのヒープトレースイベントを記録することが可能になります。Fortran 関数 allocate および deallocate は C 標準ライブラリ関数を呼び出すため、これらのルーチンは間接的にトレースされます。

Java プログラムのヒーププロファイリングはサポートされません。

ヒープトレースデータは、次のメトリックスに変換されます。

表 2-3 メモリー割り当て (ヒープトレース) メトリック

ヒープトレースデータの収集は、プログラム内のメモリーリークを特定したり、メモリーの割り当てが不十分な場所を見つける上で役立ちます。

dbx デバッグツールなどで使用されることの多い、メモリーリークの別の定義では、メモリーリークとは、プログラムのデータ空間内のいずれかを指しているポインタを持たない、動的に割り当てられるメモリーブロックです。ここで使用されているリークの定義にはこの代替定義が含まれますが、ポインタが存在するメモリーも含まれます。

MPI トレースデータ

コレクタは、Message Passing Interface (MPI) ライブラリの呼び出しの際のデータを収集できます。

MPI トレースは、オープンソースの VampirTrace 5.5.3 リリースを使用して実装されます。これは次の VampirTrace 環境変数を認識します。

これらの変数については、Technische Universität Dresden Web サイトにある『Vampirtrace User Manual』を参照してください。

バッファーの制限に達したあとに発生する MPI イベントはトレースファイルに書き込まれないため、トレースが不完全になります。

この制限を撤廃してアプリケーションのトレースを完全なものにするには、VT_MAX_FLUSHES 環境変数を 0 に設定します。この設定を行うと、MPI API トレースコレクタは、バッファーがいっぱいになるたびにバッファーをディスクにフラッシュします。

バッファーのサイズを変更するには、VT_BUFFER_SIZE 環境変数を設定します。この変数の最適値は、トレース対象のアプリケーションによって異なります。小さな値を設定すると、アプリケーションに利用できるメモリーは増えますが、MPI API トレースコレクタによるバッファーのフラッシュが頻繁に行われるようになります。このようなバッファーのフラッシュによって、アプリケーションの動作が大幅に変化する可能性があります。その一方、大きな値 (2G など) を設定すると、MPI API トレースコントローラによるバッファーのフラッシュは最小限に抑えられますが、アプリケーションに使用できるメモリーは少なくなります。バッファーやアプリケーションデータを保持するために十分なメモリーを利用できない場合、アプリケーションの一部がディスクにスワップされて、アプリケーションの動作が大幅に変化する可能性があります。

次のリストに、データが収集される関数を示します。

MPI トレースデータは、次のメトリックスに変換されます。

表 2-4 MPI トレースメトリックス

MPI 時間は、MPI 関数で費やされたスレッド合計時間です。MPI 状態の時間も収集される場合、MPI_Init および MPI_Finalize 以外のすべての MPI 関数については、MPI 作業時間と MPI 待機時間の合計が MPI 作業時間にほぼ等しくなるはずです。Linux では、MPI 待機および MPI 作業はユーザー CPU 時間とシステム CPU 時間の合計に基づきますが、MPI 時間は実際の時間に基づくため、数値は一致しません。

MPI のバイトおよびメッセージのカウントは、現在のところ 2 点間のメッセージについてのみ収集され、集合的な通信機能に関しては記録されません。MPI 受信バイト数は、すべてのメッセージで実際に受信したバイト数をカウントします。MPI 送信バイト数は、すべてのメッセージで実際に送信したバイト数をカウントします。MPI 送信数は送信したメッセージの数をカウントし、MPI 受信数は受信したメッセージの数をカウントします。

MPI トレースデータの収集は、MPI 呼び出しが原因となる可能性のある、MPI プログラム内のパフォーマンスの問題を抱えている場所を特定する上で役立ちます。パフォーマンスの問題となる可能性のある例としては、負荷分散、同期遅延、および通信のボトルネックがあります。

大域 (標本収集) データ

大域データは、コレクタによって標本パケットと呼ばれるパケット単位で記録されます。各パケットには、ヘッダー、タイムスタンプ、ページフォルトや I/O データなどのカーネルからの実行統計情報、コンテキストスイッチ、および各種のページの常駐性 (ワーキングセットおよびページング) 統計情報が含まれます。標本パケットに記録されるデータはプログラムに対して大域的であり、パフォーマンスメトリックスには変換されません。標本パケットを記録するプロセスを標本収集と言います。

標本パケットは、次の状況で記録されます。

• IDE のデバッグ中や dbx で、プログラムが何らかの理由 (ブレークポイントなど) により停止したとき (このためのオプションが設定されている場合)。

• 標本収集の間隔の終了時 (定期的な標本収集を選択している場合)。標本収集の間隔は整数値 (秒単位) で指定します。デフォルト値は 1 秒です。

• dbx collector sample record コマンドを使用し、標本を手動で記録したとき。

• このルーチンに対する呼び出しがコードに含まれている場合に collector_sample を呼び出したとき (「データ収集のプログラム制御」を参照)

• collect コマンドで -l オプションが使用されている場合に指定した信号が送信されたとき (collect(1) のマニュアルページを参照)

• 収集が開始および終了したとき

• dbx collector pause コマンドで収集を一時停止したとき (一時停止の直前)、および dbx collector resume コマンドで収集を再開したとき (再開の直後)。

• 派生プロセスが作成される前後

パフォーマンスツールは、標本パケットに記録されたデータを使用して、時間期間別に分類します。この分類されたデータを標本と呼びます。特定の標本セットを選択することによってイベントに固有のデータをフィルタできるので、特定の期間に関する情報だけを表示させることができます。各標本の大域データを表示することもできます。

パフォーマンスツールは、標本ポイントのさまざまな種類を区別しません。標本ポイントを解析に利用するには、1 種類のポイントだけを記録対象として選択してください。特に、プログラム構造や実行シーケンスに関する標本ポイントを記録する場合は、定期的な標本収集を無効にし、dbx がプロセスを停止したとき、collect コマンドによってデータ記録中のプロセスにシグナルが送られたとき、あるいはコレクタ API 関数が呼び出されたときのいずれかの状況で記録された標本を使用します。