问题标签 [perfview]

在我分析 ASP.NET Core 应用程序后，JetBrain 的 dotTrace工具默认打开All Calls选项卡并显示线程列表。

你能澄清我的一些问题吗？

• 在我的分析会话期间，我向 Web 应用程序发送了大约 10 万个请求。这些线程（除了Main一些系统线程，如Finalizer线程）是线程池用来根据下图处理所有这些请求的唯一线程吗？

• 理想情况下，我希望了解占用大量 CPU 的函数的详细信息（即分析会话中最热门的方法），所以我一直想知道这个线程视图实际上有什么帮助？

• 您是否认为线程池中可能有更多线程可以被使用并返回到线程池，但是分析器只能“捕获”特定线程池线程的信息，因为这些线程池线程是在那段时间执行？我这样说是因为对于 ~100K 请求，这里显示的线程数似乎更少，但我可能是错的。（可能是基于执行的并发请求数？）

我目前对 ASP.NET Core 应用程序进行 CPU 采样，向它发送大量请求（> 500K）。我看到应用程序的峰值工作集约为 300 MB，考虑到对应用程序发出的请求数量，我认为这并不大。但是我观察到的是，当我在我的应用程序中启用某些功能时，每秒请求数会大幅下降。

问题： 我也应该进行内存分析吗？我问这个是因为即使峰值工作集约为 300MB，可能会有大量的短期对象可以由 GC 创建和收集，并且由于 GC 的工作也算作 CPU，我是否也应该进行内存分析以查看是否我分配太多？

根据我在网上看到/阅读的一些 PerfView 材料，如果Metric/msec接近1（例如：0.92），我应该深入研究进一步的 CPU 调查，但我看到在我的情况下这个值是10.62. 这是什么意思？

总计 Metric: 218,443.0 Count: 218,443.0 First: 353.835 Last: 20,927.284 Last-First: 20,573.449 Metric/Interval: 10.62 TimeBucket: 686.0 TotalProcs 12

从Last-First中，我可以看到分析完成了 20,573 毫秒，但它Metric是 218,443 个样本。怎么来的？由于 PerfView 每 1 毫秒采样一次，我不应该看到这个值大于 20,573，对吧？

这个计数这么高是因为Metric所有这 12 个处理器都在这里吗？如果是，那么我应该像 那样进行计算(218443/12)/20573，得到 0.88 吗？

目前我们的 .net 核心应用程序正在使用 100% 的 cpu 利用率和非常小的吞吐量，在使用 perfview 后它只显示 ntdll!?，而且我所有的线程都包含无法解析的同一类（即使在符号查找之后）。

其他人有过这种经历吗？

我正在使用https://www.nuget.org/packages/Microsoft.Diagnostics.Tracing.TraceEvent/订阅内核 ETW 事件。

是否可以监视文件重命名以便我知道以前和新的文件路径是什么？

我认为这很简单，需要挂钩到FileIORename事件，但有效负载 ( FileIOInfoTraceData) 仅包含属性中的前一个文件路径FileName。

我需要写一条日志消息并在PerfView中捕获它。我想避免使用EventLog或EventSource因为它们非常具有侵入性：它们需要注册一个新的源或 ETW 提供程序，这会在系统中留下剩余的东西。

理想情况下，我只想调用Debug.WriteLine（使用OutputDebugString），但似乎 PerfView 无法收集它。或者是否有一些 ETW 提供程序可以看到调试消息？

如果您有答案，请说明解决方案的两个部分：

1. 我应该用 C# 写什么，以及
2. 如何配置 PerfView 来捕获它（如果有一些 ETW 提供程序，只需命名它）。

logman 工具可以列出当前为正在运行的跟踪事件会话启用的所有提供程序，例如：

这是如何使用 TraceEvent 库在代码中实现的？

https://www.nuget.org/packages/Microsoft.Diagnostics.Tracing.TraceEvent/

我们怀疑我们在运行几个 ASP.NET Core API 和几个 .NET Core 控制台的服务器上遇到线程池饥饿问题。

我在我们的一台服务器上运行 perfview，因为我们怀疑线程池不足的问题。但是，我在分析结果时遇到了一些麻烦。

我跑PerfView /threadTime collect了大约60秒。这就是我得到的结果（我选择了一个来查看我们的 ASP.NET Core API 之一）：

查看“按名称”我们可以看到有很多时间花费在BLOCKED_TIME. 如果我双击然后我将进入以下视图，我可以在其中展开其中一个节点以获得以下视图（被覆盖的部分是我们的 API 进程的名称）：

那告诉我什么？我不应该能够看到到底是什么阻塞了吗？看起来问题是很多线程阻塞了每个线程一小段时间吗？

我们可以从中得出任何其他结论吗？

我正在尝试使用 PerfView 找出 CPU 性能问题，我的应用程序是在 IIS 上运行的 Asp.Net Core 2.2。根据此视频https://channel9.msdn.com/Series/PerfView-Tutorial/PerfView-Tutorial-2-A-Simple-CPU-Performance-Investigation “调用者”是查找性能问题的重点，但是在我的收藏中，它只显示一个“ROOT”条目，并且不可扩展，请参阅：

有什么帮助吗？

Tks

我们使用 实现结构化日志记录System.Diagnostics.Tracing.EventSource，并在收集跟踪时使用内联提供程序清单，以避免使用 EventRegister 和 wevtutil 的安装问题。我们将 EventSource 设计为以足够低的容量进行连续、持久的日志记录。我正在努力使用 Microsoft 提供的一系列 ETW 控制器来实现收集。我想定义一个 ETW 会话：

• 为我的 ETL 文件设置最大文件大小
• 当 ETL 文件达到最大大小时，滚动到具有递增版本/时间戳信息的新文件。我不想要覆盖旧事件的循环日志。我们将自行管理存档。
• 在每个新文件中从事件流的开头维护清单数据 - 请记住，我们使用的是内联提供程序清单。

我使用以下 logman 命令关闭了（指定的提供程序 guid 来自自定义事件源）：

logman start "Session" -p "{55a51afc-22e0-5581-6db2-01d5bbe42500}" -mode newfile -max 1 -o .\test%d.etl -ets

在 Perfview 中查看，生成的第一个 ETL 文件看起来很棒：

每个后续文件如下所示，大概是因为清单数据丢失了：

我可以向 logman 提供一个选项来满足我的第三个要求吗？Vance Morrison在他的博客中暗示ETW 支持 CaptureState 命令来重新发送清单数据：

循环缓冲区情况的解决方案是要求 EventSource 在跟踪结束时再次转储其清单（它肯定会在窗口中）。这只是需要的一堆“破败”的一个例子。ETW 通过“CaptureState”命令支持这一点。

如果 logman 无法做到这一点，那么其他 ETW 控制器之一能否满足我的所有要求？我对 perfview、windows 性能记录器、xperf、tracelog 或任何其他我错过的东西持开放态度。