我有一个这样的跟踪，由 perfview 完成：

它应该与“线程时间”开关一起使用。我不明白为什么活动会这样嵌套。我很确定对文件的请求是由浏览器独立发出的，它们之间没有关系。基本上文件应该被缓存。所以字节数组只是异步复制到输出流中。

• 为什么活动是嵌套的？
• mycontext 中的 UNKNOWN_ASYNC 可能意味着什么？

编辑：添加了生产中的镜头，使用量要少得多。

我怀疑我的问题与性能测试有关。我将尝试在负载下重现此行为。

查看 PerfView 中 CPU 堆栈的截图，我不确定如何解释第一条记录。

我不能安全地排除记录，因为 CallTree 中的每个线程都以此帧开头。但困扰我的是为什么帧需要独占 181 秒以及如何使用 thre 帧。

我应该在 CPU 堆栈中安全地忽略它吗？

它在内部做什么需要时间（因为它显示有这么多的独占时间）？

编辑

如果我在 GroupPats 部分中选择“无组”（即空字符串），则该ntdll!RtlUserThreadStart帧位于末尾（它“几乎不占用” CPU 时间）。还有很多低级函数调用我无法轻松解释，因为它们是在内部调用的，但总的来说它要好得多..

Edit2（用于 usr）

我今天拍摄了 PerfView 会话。它是服务器应用程序，所以有很多线程。所以视图对于单线程来说是可以的，但对我的目的来说不是很有价值。我想基本上看按名称视图，但我很不确定那里的 RtlUserThreadStart 是什么意思..

所以我有一个 WCF 服务，我在我的开发机器上的控制台应用程序中托管。我在同一台机器上运行PerfView来收集 ETW（Windows 事件跟踪）事件。WCF 服务使用 TPL（任务并行库），我试图在 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.

最后一件事可能是相关的，我使用的是NuGet 包Microsoft.Diagnostics.Tracing中的命名空间，而不是框架中内置的命名空间。Microsoft.Diagnostics.Tracing.EventSourceSystem.Diagnostics.Tracing

编辑

这是一张显示从 TplEventSource 捕获的所有事件类型的图像。我假设这意味着 TplEventSource 已启用。我不清楚我是否应该在列表中看到“转移事件”，或者其中一个事件是否应该有一个关键字或其他表明它是转移的字段。如果应该有一个实际的“转移事件”，我在列表中看不到任何类似的东西。

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 性能分析器，但我看不到如何获得类似于数据表中显示的活动持续时间的任何内容 - 类似于PerfView中的 DURATION_MSEC 计算列。我注意到持续时间可用作通用事件图表上的工具提示，因此该信息似乎在工具中可用。

有谁知道如何在WPA中进行设置？

Perfiew 是一个非常酷的工具。但是我在使用它的调用树视图时遇到问题，因为它一次显示信息线程 - 这真的违背了目的，除非你有 1 个非常繁忙的线程。见下图。

相反，我希望通过低于线程 ID 的方式查看最昂贵的堆栈，例如顶级方法（如 ANTS 和大多数其他性能分析器所做的）。这可能吗？如果是这样，怎么做？

见下图

我想在生产服务器上运行 PerfView -> Collect with default CPU Sample Interval一段时间。另外，我想使用 Take Heap Snapshot 来检查内存泄漏。这是一个好的决定吗？它如何影响服务器资源和服务器应用程序的响应能力？

我有一个演示解决方案，它使用 System.Diagnostics.Tracing.EventSource 类引发事件。我的课程如下：-

我按照此处给出的步骤使用 PerfView 工具查看此解决方案生成的事件。我已经*DemoEvent在 PerfView 的附加提供者部分给出了。但是，我无法在 PerfView 的输出中看到这些事件。有人能帮我一下吗？

我在生产中有一个在调试中编译的 C# (.net 4.5) 服务。一天之内，它泄露了 900mb 的内存。实际上使用了10gb的内存。

所以我尝试用 perfview 做一个差异，但我找不到我的 900mb 泄漏。

我可以看到无法访问的内存增加了大约 1000mb。这是什么意思？

所以基本上，我认为没有真正的内存泄漏。正如我所料，也许 GC 不工作。

我该怎么做才能找到导致每天内存消耗增加 400mb-900mb 的原因？

我正在测量我们解析日志文件的自定义工具。CPU 堆栈如下所示：

Process32 LogScanner 有 231505 个独家样本。这可能意味着什么？

在测量其他应用程序时，我通常会看到ntdll!_RtlUserThreadStart框架，并且有很多线程并且该应用程序是 CPU 密集型的。

我正在使用PerfView进行内存泄漏调查，我正在关注这个和这个视频。

但是，我正在调查的服务器已经占用了大约 100% 的内存，所以当我尝试转储 GC 堆时，我得到一个OutOfMemoryException并且根本没有创建转储文件。PerfView日志文件具有以下内容：

当所有内存都已经被占用时，是否可以收集内存转储？