问题标签 [perfview]

我发现 PerfView 是确定各种类型问题的根本原因的非常有用的工具。但是我不确定它是否也可以用来诊断 LOH 碎片问题。我使用 PerfView 收集了一个进程内存快照。在过去的这个过程中，我们观察到了 LOH 碎片，但当时我曾经从 !heapstat 命令中获取值。任何人都知道 PerfView 是否可以帮助确定：

1. LOH 的碎片化程度有多严重
2. 哪些对象可能导致这种碎片

我正在尝试调查我的应用程序的内存问题。这是 .NET 堆大小。

当我运行 perfView 时，它显示 AsyncPinned 句柄占用了大部分内存，如下所示。

这就是 !Gchandles 所展示的。

我对 AsyncPinned 句柄了解不多，但我怎么知道哪些对象正在创建这些句柄，谁在阻止这些句柄，为什么这些没有得到清理？

编辑 我已经阅读了为此重复的链接，但我试图找出如何知道这些 AsyncPinned 句柄是在哪里创建的，该链接中没有解释

我在 Windows Server 2012 上运行 PerfView。它在 VMware VM 上运行。如下图所示，所有进程的 CPU 为 0。

我应该从哪里开始调试？

我正在对用作集成服务的 Windows 服务中的内存泄漏进行故障排除。

每次“doIntegration()”调用我可以看到内存使用率比调用前更高，并且每次调用增加了大约 0.5 MB。

我尝试使用 PerfView 来定位内存泄漏的可能位置。

故障排除方法：

1) 在第一次 doIntegraion 调用之前获取堆快照

2) 在 doIntegration 调用后获取堆快照

3) 多次执行第 2 步

4）检查每次调用哪个方法/组更高

5）使用单独快照上的差异来定位内存泄漏的位置

我可以看到LIB mscorlib!RuntypeType是每次都变高的方法/组。当我尝试检查引用它的内容时，我得到

• 固定手柄
  • .NET 根
    • 根

而且我无法进一步扩展树。

当我选择视图时，RefTree 我可以看到更多的东西。

• 根 100%
  • .NET 根 100%
    • 固定手柄 70.6%
      • LIB mscorlib!RuntimeType 46%
      • LIB mscorlib!reflection.... 13.4% ...
    • 静态变量 30.7%
      • ns.ConfigurationSettings 5​​9.5%
      • ns.Leaks.ConfigurationSettings -33.3%

我对几个快照进行了比较，唯一增加的方法/组是固定句柄，它们只引用 mscorlib 类型。

有没有其他人遇到过这种问题？

我认为问题可能在于使用 XMLSerializer 从模型到 XML 的序列化，但我不太确定。

有谁知道另一种尝试查找内存泄漏的方法？

谢谢 ：）

我的日志库中有这段代码

根据我使用 PerfView 工具进行的性能分析，它显示为

有谁知道我添加的代码对性能的影响？如果是，有没有其他方法可以让我获得方法名称而不会对性能产生更大的影响？

我目前在 4 核机器上以 1000 TPS 运行它。而且我看到它使用了我的 CPU 的 15.1%

我的库中有这段代码，每次创建新请求时，它都会调用此方法。所以基本上每秒的请求数是 1000 次，那么它将被调用 1000 次。当我使用 PerfView 工具时，我注意到这种方法使用了 35% 的 CPU。最大的罪魁祸首是 store.Open 和 store.Certificates.Find 方法。

其他任何人都在他们的代码中发现了类似的问题。此外，如果您可以分享您为解决由此造成的性能影响所做的工作。

我很困惑如何EventListener为现有系统 ETW Provider 创建一个。该EnableEvents方法期望在EventSource实例中传递。我需要手动创建吗？有没有办法生成那个EventSource类？

我可以找到提供者的详细信息：

我什至可以instrumentationManifest使用以下命令生成 xml：

我一直无法触发OnEventWritten，我不知道为什么。有任何想法吗？

2015-12-02 更新

我能够EventSource使用 SemanticLogging 获取事件记录。详情在这里。它正在使用Microsoft.Diagnostics.Tracing.TraceEvent。使用它似乎可能是解决方案。

我有相对较小的 etl 文件（总共 100MB），但是当我单击 GC Heap Net Mem Stacks 并等待很长时间（10 分钟以上）时，它永远不会从“灰色状态”中恢复过来。

如果这是否“正常”，有什么想法吗？

我运行 perfview 并查看了 GC 事件。在 perfview 事件视图中可以找到一个事件列表 - https://msdn.microsoft.com/en-us/library/ff356162(v=vs.100).aspx

我的问题是：我在哪里可以找到未在https://msdn.microsoft.com/en-us/library/ff356162(v=vs. 100).aspx ? 它们的含义是什么？

我在生产系统上运行 perfview（只是默认集合），其中 CPU 在几分钟内达到 100%。我得到了一些有用的结果，但是我也得到了一堆 BROKEN 堆栈。

机器是 Windows Server 2012 R2。该应用程序是一个启动的exe。该应用程序在 .NET 4.0 中编译，但服务器运行的是 .NET 4.6.1

perfview 帮助说，这些针对我的情况的 BROKEN 堆栈已在 Windows 8 中修复（我猜也是 Windows Server 2012）。我的 dll 不是 ngen-ed，但我认为我不必这样做，好吧，问题已在 Windows 8 中修复

有什么想法吗？