问题标签 [perfview]

我正在尝试查看 Object[] 项（固定句柄）是什么以及它的来源，Perfview但是当我双击它时，只会给我一个 ROOT、.NET 根、固定句柄、LIB 的高级视图。有没有办法查看是什么创建了该内存或方法位置？

有谁知道为什么我使用 PerfView 和集合的进程/文件/注册表堆栈部分对 FileOpenOrCreate 进行数千次调用以查找随机 .cshtml 和 .vbhtml 文件？

有没有办法确定在 PerfView 中进行调用的线程的 URL？此截图来自 GC Heap Net Mem。

我在 linux 上的 dotnet aspnetcore (3.1) 服务上遇到线程池饥饿问题的周期性峰值。值得注意的是，由于某种原因，在 Windows 上完全没有这个问题。

我使用 dotnet-trace 捕获跟踪并得出结论，我确实捕获了感兴趣的区域，因为事件包含多个线程启动事件。

现在我正在努力理解是什么阻塞了我的几十个线程，从而导致线程池创建了另外一百个。

我已经阅读了多个文档和文章，但仍然无法完全理解线程非活动和活动之间有什么区别。在线程时间视图中，我可以看到在非活动节点下方具有堆栈的节点。下面的例子。具体来说，该节点位于非活动节点下方。怎么解释？如果非活动意味着线程没有做任何事情的时间，为什么我会在给定时间区域内的时间桶中看到许多样本？这是否意味着这个线程实际上被阻塞在这个堆栈中？

我知道有一个命令可以从一个进程收集 ETW 事件：“perfview collect -OnlyProviders:”*:@ProcessNameFilter=my.process.exe“”。但是如何从某些特定进程中收集 ETW 事件呢？我们使用逗号和分号来指定两个或更多进程，但它不起作用。

在过去的几天里，我一直在使用 PerfView 在我们的一台生产 Web 服务器（.net 4.7.2 和 ASP.NET - MVC 5.2.4）上寻找广泛的大对象堆分配并监控 GC 性能，我使用了“ GC Collect Only”、“GC Only”、“ETW .NET Alloc”选项以及可能的其他一些选项。

然而，在跟踪会话期间和之后，CPU 使用率非常高，长达 10 秒，其中所有 24 个内核的利用率几乎为 100%。在 PerfView 会话停止并且问题仍然存在后，我执行了“issreset”并最终重新启动了网络服务器。但这并没有帮助，在加入集群 15 到 20 分钟后，服务器开始再次看到高 CPU 利用率。此时，我在 CPU 使用率较高时创建了一些进程的转储，并使用 DebugDiag 对其进行分析，这表明 GC 正在运行。

所以我的问题是，什么会导致应用程序以这种方式运行？上周，该网站在该服务器上运行平稳，另外 2 个在过去几天没有出现问题的网络服务器也运行良好。是否存在某种在重启后仍然存在的挥之不去的跟踪会话？

我正在运行此命令来收集阈值为 75 的 Perfview 的高 cpu 问题。正如您所看到的，它已经在做某事，正在收集东西。似乎还有一个 3 秒的触发器。我希望它在被击中 75 之前收集并且不占用空间，但看起来并没有这样做。我也可以将触发器设置为更大的数字，超过 75 时看起来是 3？

我试图让 Perfview 在 W3WP 服务超过 90% CPU 时执行。但是它说的是118.5？我不确定这个数字来自哪里，但我的 CPU 没有超过 20%。

让我们考虑一个简单的案例——我在 Windows 上运行一个 .net5 控制台应用程序。如果我通过PerfView /threadTime collect像这里描述的那样获取跟踪，那么我可以在Thread Time Stacks选项卡中看到BLOCKED_TIME指标。我应该如何运行dotnet-trace命令以在Perfview中获得相同的指标？我尝试过使用详细程度，但到目前为止还没有运气。

Is there a way to find this path where this error happened with Perfview?