私は perfview によって行われたこのようなトレースを持っています:

「スレッド時間」スイッチで撮影する必要があります。理解できないのは、アクティビティがこのようにネストされている理由です。ファイルのリクエストはブラウザによって個別に行われ、それらの間に関係はないと確信しています。基本的に、ファイルはキャッシュされるべきです。そのため、バイト配列は非同期で出力ストリームにコピーされます。

• アクティビティがネストされているのはなぜですか?
• また、mycontext の UNKNOWN_ASYNC は何を意味するのでしょうか?

編集：使用量がはるかに少ないプロダクションからのショットを追加しました。

私の質問は、何らかの形でパフォーマンス テストに関連していると思われます。負荷がかかった状態でこの動作を再現しようとします。

PerfView で CPU スタックからのショットを見ると、最初のレコードを解釈する方法がわかりません。

CallTree のすべてのスレッドがこのフレームで始まるため、このレコードを安全に除外することはできません。しかし、私を悩ませているのは、フレームが排他的に181秒かかる理由と、3フレームの操作方法です。

CPU スタックで安全に無視する必要がありますか?

時間がかかるのは内部で何をしているのでしょうか（非常に多くの排他的な時間で表示されます）？

編集

GroupPats 部分で「グループなし」(空の文字列) を選択すると、ntdll!RtlUserThreadStartフレームは最後になります (CPU 時間はほとんど「かかりません」)。内部で呼び出されるため、簡単に解釈できない低レベルの関数呼び出しもたくさんありますが、全体的に見るとはるかに優れています..

Edit2 (ユーザー用)

今日、PerfView セッションを撮影しました。サーバーアプリなのでスレッド数が多いです。したがって、ビューはシングルスレッドでは問題ありませんが、私の目的にはあまり価値がありません。基本的にBy Nameビューを見たかったのですが、そこにあるRtlUserThreadStartが何を意味するのかよくわかりません..

そのため、開発マシンのコンソール アプリケーションでホストしている WCF サービスがあります。同じマシンでPerfViewを実行して、ETW (Event Tracing for Windows) イベントを収集しています。WCF サービスは TPL (Task Parallel Library) を利用しており、WCF 要求の存続期間全体にわたって、すべてのスレッドで ETW イベントを関連付けようとしています。私はクライアントとサーバーの間ではなく、サーバー上で厳密に話しています。ただし、PerfViewでイベントを見て、カスタムからのイベントのみにビューをフィルター処理すると、EventSource一部のスレッドのイベントのみにActivityId. 任意のスレッドについて、すべてのイベントに があるか、どのイベントにもないかのいずれかActivityIdです。また、どのイベントにもRelatedActivityId.

このリンクはセマンティック ロギング アプリケーション ブロック (SLAB) に関連していますが、その中で次のことが言及されています。

TPL タスクを使用する場合、各スレッドは独自のアクティビティ ID を取得し、TPL スケジューリング コードは、ActivityId 値と RelatedActivityId 値を含む転送イベントを自動的に発行します。これらを使用して、関連するイベントを関連付けることができます。

それは私にはまったく当てはまらないようです。アクティビティ ID を関連付ける転送イベントが表示されないだけでなく、多くの場合、前述のように、アクティビティ ID が完全に欠落しています。

この SO の回答によると: https://stackoverflow.com/a/27620321/1937249 :

アウト プロセス リスナーを使用する場合、名前による TPL 構成が機能せず、代わりに GID が使用されるというバグがあります: https://slab.codeplex.com/workitem/62

そこで、イベント ソースの GUID を次のように名前の代わりにPerfView の「追加プロバイダー」に追加してみました。

しかし、違いはありませんでした。私のイベントは公開されましたが、それらの多くはまだそれらがなくActivityId、すべてのイベントでそれらがありませんでしたRelatedActivityId.

関連する可能性のある最後の 1 つのことは、フレームワークに組み込まれているものではなくMicrosoft.Diagnostics.Tracing、NuGet パッケージの名前空間を使用していることです。Microsoft.Diagnostics.Tracing.EventSourceSystem.Diagnostics.Tracing

編集

TplEventSource からキャプチャされたすべてのイベント タイプを示す画像を次に示します。TplEventSource が有効になっていることを意味すると思います。リストに「移籍イベント」が表示されるべきなのか、それともイベントの 1 つに移籍であることを示すキーワードやその他のフィールドが必要なのか、はっきりしません。実際の「転送イベント」があると思われる場合、リストにそのようなものは表示されません。

PerfView の出力

EventSourceこれは、単一の WCF 要求に対するカスタムのイベント リストの図です。リクエストがスレッド ID 10,724 で開始されていることがわかります。そのスレッドのすべてのイベントにはActivityId. 「Asi-Geoservices/StartAuthenticateRequest/Start」は非同期データベース呼び出しを行い、アプリケーションはスレッド 8,268 で再開します。スレッド 8,268 のイベントにはActivityId. 「Asi-Geoservices/StartServiceProviderRequest/Start」は非同期 HTTP リクエストを作成し、アプリケーションはスレッド 11,764 で再開します。ここでも、このスレッドの各イベントにはActivityId. 「Asi-Geoservices/StartServiceProviderRequest/Stop」の後、別の非同期データベース呼び出しが行われ、アプリケーションがスレッド 8,268 で再び再開され、そこでリクエストが最終的に完了します。ActivityId.

私は ETW とSystem.Diagnostics.Tracing.EventSourceに基づくいくつかのカスタム イベントをいじっています。それはすべて TPL でうまく機能しています。つまり、異なるスレッド間でも相互に関連するアクティビティが得られます。すべてが非常に優れています。PerfViewを使用して、これが正しく機能していることを検証しています。

分析でWindows Performance Analyzerの使用を開始したいと考えていますが、データ テーブルに表示されるアクティビティ期間に似たもの ( PerfViewの DURATION_MSEC 計算列など) を取得する方法がわかりません。Generic Events グラフのツールチップとして期間が利用できることに気付きました。この情報はツールで利用できるようです。

これをWPAで設定する方法を知っている人はいますか?

Perview は非常に優れたツールです。ただし、一度に情報スレッドが表示されるため、コールツリービューの使用に問題があります。これは、本当にビジーなスレッドが1つない限り、目的を実際に無効にします。下の画像を参照してください。

代わりに、おそらくトップレベルのメソッドのように、スレッド ID よりも低いもので最も高価なスタックを確認したいと考えています (ANTS や他のほとんどのパフォーマンス プロファイラーが行うように)。それは可能ですか? もしそうなら、どのように？

下の画像を参照してください

System.Diagnostics.Tracing.EventSource クラスを使用してイベントを発生させるデモ ソリューションがあります。私が持っているクラスは以下の通りです： -

こちらの手順に従って、PerfView ツールを使用して、このソリューションによって生成されたイベントを表示しました。*DemoEventPerfView の additionalProvider セクションで指定しました。ただし、PerfView の出力でこれらのイベントを確認できません。誰でもここで私を助けることができますか?

デバッグでコンパイルされた本番環境の C# (.net 4.5) サービスがあります。1 日で 900MB のメモリがリークしました。実際には10GBのメモリを使用します。

そこで、perfview で差分を作成しようとしましたが、900MB のリークが見つかりません。

私が見ることができるのは、到達不能メモリが約1000MB増加したことです。これは何を意味するのでしょうか？

基本的に、実際のメモリリークはないと思います。予想どおり、GC が機能していない可能性があります。

メモリ消費量が 1 日あたり 400 mb ～ 900 mb 増加する原因を見つけるにはどうすればよいですか?

ログ ファイルを解析するカスタム ツールを測定しています。CPU スタックは次のようになります。

Process32 LogScanner には、231505 の排他的なサンプルがあります。それはどういう意味ですか？

私は通常、ntdll!_RtlUserThreadStart他のアプリケーションを測定するとフレームが表示され、多くのスレッドがあり、アプリは CPU を集中的に使用します。

PerfViewを使用してメモリ リークの調査を行っており、これとこのビデオをフォローしています。

ただし、調査しているサーバーは既にメモリの約 100% を使用しているため、GC ヒープをダンプしようとするOutOfMemoryExceptionと、ダンプ ファイルがまったく作成されません。PerfViewログ ファイルには次の内容が含まれます。

すべてのメモリが既に使用されている場合、メモリ ダンプを収集することはできますか?