クロックプロファイリングのイベント固有のデータは、プロファイリング間隔カウントの配列で構成されています。Oracle Solaris では、間隔カウンタが提供されます。プロファイル間隔の最後で適切な間隔カウンタが 1 増分され、別のプロファイル信号がスケジューリングされます。配列が記録およびリセットされるのは、Solaris スレッドが CPU ユーザーモードに入った場合だけです。配列のリセット時には、ユーザー CPU 状態の配列要素が 1 に設定され、ほかの全状態の配列要素が 0 に設定されます。配列データが記録されるのは、配列がリセットされる前にユーザーモードに入るときです。そのため、この配列には、Solaris スレッドごとにカーネルによって保持されている 10 マイクロステートのそれぞれについて、前回ユーザーモードに入ってから開始されたマイクロステートごとのカウントの累計値が含まれます。Linux オペレーティングシステムでは、マイクロステートは存在しません。唯一の間隔カウンタは「ユーザー CPU 時間」です。
呼び出しスタックは、データと同時に記録されます。プロファイル間隔の最後に Solaris スレッドがユーザーモードになっていない場合は、そのスレッドが再びユーザーモードに入るまで、呼び出しスタックを変更できません。そのため、呼び出しスタックには、各プロファイリング間隔の最後のプログラムカウンタの位置が常に正確に記録されます。
Oracle Solaris で各マイクロステートが関連しているメトリックをTable 6–1 に示します。
|
タイミングデータは統計データとして収集されるため、あらゆる統計的な標本収集手法のすべての誤差の影響を受けます。プログラムの実行時間が非常に短い場合は、少数のプロファイルパケットしか記録されず、多くのリソースを消費するプログラム部分が、呼び出しスタックに反映されないことがあります。このため、目的の関数またはソース行について数百のプロファイルパケットを累積するのに十分な時間または十分な回数で、プログラムを実行するようにしてください。
統計的な標本収集の誤差のほかに、データの収集?関連付け方法、システムにおけるプログラムの実行の進み具合を原因とする誤差もあります。次に示す環境などでは、タイミングメトリックでデータに不正確さやひずみが生じる可能性があります。
スレッドが作成されるとき、最初のプロファイルパケットが記録される前に費やされる時間はプロファイリング間隔より短くなりますが、プロファイリング間隔全体は最初のプロファイルパケット内に記録されるマイクロステートに従います。多数のスレッドが作成された場合、エラーはプロファイル間隔の何倍にもなることがあります。
スレッドが破棄されたとき、一部の時間は、最後のプロファイルパケットが記録されたあとに費やされます。多数のスレッドが破棄された場合、エラーはプロファイル間隔の何倍にもなることがあります。
プロファイル間隔中に、スレッドの再スケジュールが発生する場合があります。その結果、そのスレッドの記録された状態が、プロファイル間隔のほとんどが費やされたマイクロステートを表していない可能性があります。これらのエラーは、スレッドを実行するプロセッサより、実行されるスレッドの方が多い場合にさらに大きくなる可能性があります。
プログラムがシステムクロックと相関関係を持つ形で動作することがあります。この場合は、スレッドが、費やされた時間のごく小さい部分を表しているような状態であると、プロファイリング間隔が常に期限切れになるため、プログラムの特定部分に対して記録された呼び出しスタックは過剰に表されます。マルチプロセッサシステムでは、プロファイリングシグナルによって相互関係が引き起こされる場合があります。プログラムのスレッドを実行中にプロファイリングシグナルによって中断されたプロセッサは、マイクロステートが記録されるときに Trap-CPU マイクロステートにある可能性があります。
カーネルは、プロファイル間隔の時間切れになったときにマイクロステート値を記録します。システムが過負荷状態の場合、この値に、プロセスの本当の状態が反映されないことがあります。Oracle Solaris では、この状況によって、Trap-CPU または Wait-CPU マイクロステートの過剰アカウンティングが発生する可能性があります。
システムクロックが外部ソースと同期されている場合、プロファイルパケット内に記録されるタイムスタンプにはプロファイリング間隔が反映されませんが、クロックに対して行われた調整はすべて含まれます。 システムクロック調整の結果、プロファイルパケットが失われたかのように見える可能性があります。その時間は通常数秒間であり、調整は一定の増分単位で行われます。
動作クロック周波数が動的に変わるマシンで記録された実験には、プロファイリングの不正確さが反映されていることがあります。
今説明した不正確さに加えて、データ収集のプロセスによってタイミングメトリックにひずみが生じます。記録はプロファイリングシグナルによって開始されるため、プロファイルパケットの記録に費やされた時間がプログラムのメトリックに現れることはありません。これは、相関関係の別の例です。記録に費やされたユーザー CPU 時間は、記録されるあらゆるマイクロステート値に配分されます。この結果、ユーザー CPU 時間のメトリックが実際より小さくなり、その他のメトリックが実際より大きくなります。デフォルトのプロファイル間隔の場合、一般に、データの記録に費やされる時間は CPU 時間の 2、3% 未満です。
時間ベースの実験のプロファイリングで得られたタイミングメトリックと、その他の方法で得られた時間を比較する場合は、次の点に注意する必要があります。
シングルスレッドアプリケーションの場合、1 つのプロセスについて記録されたスレッド合計時間は通常、同じプロセスについて gethrtime(3C) によって返された値と比較して数十分の 1 パーセントまで正確です。CPU 時間の場合は、同じプロセスについて gethrvtime(3C) によって返される値と比較して、数パーセント程度異なることがあります。負荷が大きい場合は、差がさらに大きくなることがあります。ただし、CPU 時間の差は体系的なひずみを表しません。さまざまな関数やソース行などについて報告される相対的な時間に大きなひずみは生じません。
パフォーマンスアナライザの報告するスレッド時間は、vmstat が CPU 全体にまたがって集計した時間を報告するため、vmstat の報告する時間とかなり異なることがあります。たとえば、ターゲットプロセスの LWP 数が、そのプロセスが動作するシステムの CPU 数よりも多い場合、アナライザは、vmstat が報告する時間よりもずっと長い待ち時間を報告します。
パフォーマンスアナライザの「統計」ビューや er_print 統計の表示に現れるマイクロステートタイミングは、プロセスファイルシステムの /proc 使用報告に基づいており、マイクロステートで費やされた時間が高い精度で記録されます。詳細は、proc(4) のマニュアルページを参照してください。 これらのタイミングを、全体としてのプログラムを表す <Total> 関数のメトリックと比較することによって、集約されたタイミングメトリックのおよその精度を知ることができます。ただし、「統計」ビューに表示される値には、<Total> のタイミングメトリック値には含まれないその他の関連要素が含まれることがあります。その原因は、データ収集が一時停止される期間によるものです。
ユーザー CPU 時間とハードウェアカウンタサイクル時間は異なります。なぜなら、ハードウェアカウンタは、CPU モードがシステムモードへ切り替えられたときにオフにされるからです。詳細は、トラップを参照してください。