スレッドプロファイラツール

Linuxでサポートされています。

Linux 上のスレッドプロファイリングは、.NETエージェントバージョン8.23以降を実行する場合、.NET Core 3.0以降のアプリケーションでサポートされます。

管理されたスレッドのみ

.NETエージェントの場合、スレッドプロファイラは管理されたスレッドのスタックトレースのみをキャプチャします。管理されていないスレッドのスタックトレースはキャプチャされません。管理されていない関数への呼び出しが管理されているスレッド上で発生した場合、スレッドプロファイラはコールツリーに Native:Function Call を表示します。

ラインナンバーなし

.NETスレッドプロファイルでは、コールツリーに行番号が含まれていません。ツリーの設定にある Show line numbers チェックボックスは何の効果もありません。

64bit v4.0 .NET CLRの不具合について

64ビット版の4.0 .NET共通言語ランタイム（CLR）には、エージェントが管理されたスタックトレースを取得する機能を妨害するバグがあります。アプリケーションにこのバグがある場合、APMは空のスレッドプロファイルを表示します。このバグは、32ビットアプリケーションには影響しません。

このバグは、.NET 4.5 の CLR リリースで修正されています。お使いの64ビットアプリケーションが修正されたバージョンであるかどうかを確認するには、 C:Japanese Windows\Microsoft.NET\Framework64\v4.0.30319 ディレクトリにある mscorlib.dll のフルバージョンをご覧ください。修正されたバージョンは 4.0.30319.17379 以上です。

その他 カテゴリーのみ

すべてのスレッドは、 Other カテゴリに入れられます。 Web Request と Background のカテゴリはサポートされていません。

コルーティンベースのシステム

gunicorn の gevent や eventlet モードのようなコルーチンベースのシステムを使用している場合、詳細をキャプチャするには限界があります。新しいスレッドを作成する場合、Pythonエージェントはスレッドプロファイラのバックグラウンドスレッドではなく、実際にグリーンレットを作成します。そのため、スレッドプロファイラは、スレッドプロファイラページ上のWebリクエストとバックグラウンドトランザクションをキャプチャしません。

グリーンレット

グリーンレットは，他のグリーンレットがブロックしたときなど，明示的に制御を放棄したときにのみ実行できます。例えば、スレッドサンプラが実行された場合、他のグリーンレットがブロックされた時点でのみスタックをサンプリングします。他のグリーンレットが任意のコードを実行しているときにはサンプリングしません。グリーンレットがブロックされたり、他のグリーンレットに譲ったりしていなければ、グリーンレット内の実行を完全に見逃すことができます。

Pythonコードの時間

リクエストをブロックしていない純粋なPythonコードに費やされた時間はピックアップされず、情報は記録されず、報告もされません。これは、コルーチンが使用されている場合、結果が誤解を招くためです。

バックトレース

スレッドプロファイラは、Ruby アプリケーション内からスレッドのバックトレースを取得できるかどうかに依存しています。そのため、 MRI 1.9.2 以上 (for Thread#backtrace メソッド) が必要です。

Resque

Rubyエージェントは現在、Resqueのバックグラウンド・ジョブでのスレッド・プロファイルをサポートしていません。Resqueに対して開始されたスレッド・プロファイリング・セッションは、ジョブ・プロセスではなく、親プロセスからのトレースのみをキャプチャします。

JRuby

JRuby のサポートは、現時点では実験的なものと考えられています。JRuby の Thread#backtrace の実装には、JRuby で収集されるバックトレースの精度や信頼性に影響を与える既知の問題があります。