问题标签 [perfview]

我正在研究 wcf 应用程序的内存问题，我正在使用 perfview 来挖掘内存。我们得到了一个基本快照，然后是内存高时的快照。我对它们进行了比较，并查看了我看到的未访问内存为 2,921MB 的数据。我的理解是，未到达的内存意味着它已经准备好进行 GC 处理了。已经16个多小时了，无法触及的记忆还在不断攀升。

什么会导致 GC 不收集无法访问的内存？

更新

当服务消耗大量内存时，我能够获得终结器队列的转储。我究竟应该在这份报告中寻找什么？或者也许我应该运行其他 windbg/sos/sosex 命令？

“准备完成”对象的数量对我来说很突出。那不应该是零，或者至少少于几百吗？

给定

1. 具有动态事件的实现 ETW 提供程序（继承自 EventSource）。提供者名称“IDS-IDComplete-DynamicTrace”

2. 我的 Windows 服务实现，其中生成了 ETW 的事件

3. 我使用 PerfVev 从服务中收集事件：

PerfView.exe collect ETWTrace.etl /merge /zip /OnlyProviders=*IDS-IDComplete-DynamicTrace

4. 我看到了我所有的事件。

问题

如何查看 PerfVev 中的调用堆栈，以便查看对我的代码的调用？

我正在学习 PerfView 并尝试了 GCStats 报告。我创建了一个简单的应用程序，它在堆上做了很多内存分配：

以下是我在 PefrView 中配置“运行”对话框的方法：

这是 PerfView 的 GCStats 报告：

这里是 PerfView 的日志文件，它显示了第二个 GcReport() 方法的结果：

如您所见，在 PerfView 的报告和控制台日志结果中，GC 收集的数量是不同的。有人可以解释一下，为什么数字不同？

我正在运行这个 PerfView 命令：

PerfView.exe /Merge:true /zip:true /NoNGenRundown /NoClrRundown /KeepAllEvents /ThreadTime /DumpHeap /NoView /NoGui /MaxCollectSec:30 collect

但似乎即使我定义/MaxCollectSec:30为 30 秒，实际的数据收集过程也不会停止并继续将数据添加到PerfViewData.etl文件中

这是 Perfview 在运行命令时打开的控制台窗口的输出：

详细登录：PerfViewData.log.txt

执行：PerfView /Merge:true /zip:true /NoNGenRundown /NoClrRundown /KeepAllEvents /ThreadTime /DumpHeap /NoView /NoGui /MaxCollectSec:30 收集

Pre V4.0 .NET Rundown 已禁用，键入“E”以启用 V3.5 进程的符号。

不要关闭此控制台窗口。它将继续收藏！

键入 S 停止收集，'A' 将中止。

内核日志：C:\PerfView\PerfViewData.kernel.etl

用户模式日志：C:\PerfView\PerfViewData.etl

2017 年 12 月 7 日 14:26:32 开始收集

收集 10 秒：大小 = 10.5 MB。

收集 20 秒：大小 = 16.4 MB。

超过 MaxCollectSec 30

所以这里是：Exceeded MaxCollectSec 30但继续写入 etl 文件。

我想向客户端发送一个 Perfview 命令以收集系统范围的数据并将包含来自 Perfview 的所有 ETL 文件的 zip 文件发回给我。目前命令不会停止 - 有人知道为什么吗？我应该从命令中添加/删除什么，以便它在 30 秒后自动停止？

当我尝试使用PerfView v1.9.0.0（收集 -> 收集 -> 开始收集，使用默认参数）创建 ETL 文件时，操作失败并显示“发生异常情况，请参阅日志了解详细信息。 ”

以下是我在日志中看到的内容：

当然，该文件以前从未存在过，并且在（失败的）操作之后也不存在。每次我尝试收集时都会发生这种情况，无论我提供的文件名或目录如何。

我究竟做错了什么？

我正在查看我的最慢请求之一的性能配置文件，我看到 AWAIT_TIME 超过 6 秒，但我无法获得有关它的更多信息。我如何弄清楚这个过程到底是什么“等待”？

我正在使用 Perfview 来分析垃圾收集器的性能。
我将 CLR 启动标志：CONCURRENT_GC、SERVER_GC 用于我的控制台应用程序。
速度缓慢有时出现在第 0 代、第 1 代或第 2 代。
您建议我进一步分析什么？
我怀疑 GC 正忙于与在后台使用本机代码的外部 3rd 方库有关，但我想知道如何进一步分析这一点。

我知道有一个 /Process:NameOrPID 开关，但它只影响 /StopXXX 命令。从所有进程中收集 ETW 事件会导致生成大的 *.ETL 文件。我试图能够仅从一个进程中捕获 ETW 事件，以避免用不相关的 ETW 事件污染输出文件。

在尝试让 ETW 活动跟踪在我的项目中工作了很长一段时间但没有取得多大成功之后，我想我应该退后一步，看看这个页面上提供的 Microsoft 演示项目是否对我有用。不幸的是，两者都不是。问题是，这些事件确实显示在 VS 的诊断事件窗口中，但它们有一个普通的 GUID 作为 ActivityID 而不是分层活动 ID，并且 RelatedActivityID 只包含一个空值：

尝试了几个小时后，我发现有一种方法可以让它工作：当我在生成事件的同时使用PerfView收集数据时，它们突然得到了一个他们应该得到的分层 id，甚至有相关的活动标识集：

但是，一旦我停止使用 PerfViewer 收集事件，这些事件再次只有一个活动 ID 的 GUID，并且错过了相关的活动 ID。

有谁知道为什么会这样？这真的只有在外部应用程序正在监视事件时才有效，还是我能以某种方式让它只在 VS 中工作？是否有人可能知道这是否适用于 Azure 诊断？我想稍后使用 Azure 诊断来收听事件，但如果没有以这种方式生成分层 ID，它对我来说没有多大用处。

非常感谢！

我正在对 windows 网络堆栈进行故障排除并使用 Perfview/ETW 来完成它。

我对事件源 Microsoft-Windows-TCPIP 清单中出现的一些值特别感兴趣。

使用此方法我可以毫无问题地获取清单

问题是，一旦我得到清单，它就会有一堆没有太多解释的值。

例如

我对这个 Context 值特别感兴趣，因为在我的测试用例中，我得到“Initializing Templace SYNTCB”但就是这样

我真的很想知道例如

• 在堆栈/代码中的哪个位置触发此模板更改
• 无论如何，这个 SYNTCB 模板是什么
• 哪个微软团队管理这个特定的 ETW 源，所以也许我可以以某种方式问他们一个问题..

我已经尽我所能在.net 代码库中查看 system.net（网络代码），看看那里是否有 ETW 挂钩，但我找不到任何东西......

我也可以在 Perfview 中看到该事件，但找不到保存该事件的内存堆栈（是的，我已经扩展了所有系统级事件，并下载了尽可能多的符号库）