问题标签 [dottrace]

这是我到目前为止所尝试的：

1) 使用 Kudu 将控制台工具上传到应用程序并运行它们。好吧，这是不可能的，因为不允许写入注册表。

2) 使用 Kudu 上传 RemoteAgent 并运行它。我得到： No DNS entries exist for host xxx. No such host is known.从 dotTrace UI 连接到 Kudu 控制台中打印的 URL 时。App 服务只能监听 80 和 443 端口。

3) 使用 dotTrace SDK 和 JetBrains.Profiler.Api 看起来很有希望。它不想在 Azure 上附加探查器（而不是在本地没有问题），使用此代码会遇到超时异常。

Jetbrains 的 dottrace 应该具有对 async/await 的分析支持。

但我无法让它向我展示预期的结果（我在时间线查看器调用堆栈中没有“等待”和“继续”节点）。

我尝试使用以下程序类型进行分析：

• .NET 框架（4.7）控制台程序，
• .NET框架（4.7）windows程序，
• .NET 核心 (>2.2) 控制台，
• .NET core (>2.2)windows 程序，
• .NET 核心 (3.0) wpf

这只是对我不起作用吗？因为我在互联网上找不到任何东西，或者这正式目前不再有效？

我对可能解释的唯一参考是针对控制台应用程序： https: //youtrack.jetbrains.com/issue/DTRC-26464 关于：

AsyncCausalityTracer.LoggingOn 为 false 和一些 ETW 提供程序。但对我来说，这对所有类型的应用程序都不起作用

我当前的 jetbrains 软件版本是：Resharper Ultimate 2019.2.3 (dottrace 2019.2)

--- 编辑 2019/11/01：

当点击我得到的事件时（我也希望 TPL 事件？？？）：

--- 编辑 2019/11/06：

由于 Konkat info 链接的回答中的评论，我也尝试过：

• .NET core 2.0 控制台应用程序

=> dottrace 异步支持也不起作用

我想弄清楚一个方法的单个调用的执行时间。因此，如果一个方法被调用 3 次，我可以看到它需要执行的总时间。由于每次通话的执行时间可能会有所不同，因此我想查看各个时间。

有办法看到吗？

我目前正在使用 dotTrace Timeline 分析我的应用程序。我发现很多时间都花在了 GC 上，这是意料之中的，但出乎意料的是，在后台收集期间，我看到很多时间用户线程被挂起。

探查器截图：

从图像中我看到我有两个线程在做一些 CPU 绑定的工作，然后发生“后台”GC，第一个线程稍后暂停，第二个线程立即暂停。

您可以看到用户线程确实被垃圾收集器线程阻塞。

我知道在后台 GC 期间可能会有 Gen 0 和 Gen 1 的前台阻塞 GC。但情况并非如此，因为所有 GC 都在 Gen 2 上。

我在 github 上创建了基本的复制解决方案： https ://github.com/isaevdan/BackgroundGCSuspendsThreads

我试图找出为什么我的应用程序会随着时间的推移而变慢。应用程序将要做的工作捆绑成可以同时执行的批处理。每一批都必须等待前一批完成。批处理在更新函数中每 30 毫秒执行一次。在代码中，它看起来像这样：

几天后，我发现执行所有批次的时间越来越长。起初，执行大约需要 15ms，然后几天后需要超过 100ms。我的目标是找出为什么执行时间不断增加。

在调试时，我发现批次的数量和每个批次中的动作量保持不变。

使用 dotTrace 进行分析表明，有时批处理中的一个操作需要更长的时间，并且Parallel.ForEach会（并且应该）等到所有先前的操作完成。在启动应用程序后立即进行分析时，延迟仅每几百次更新可见。几天后，几乎每次更新都会出现延迟。

这就是它在分析器中的样子；我用不同的绿色标记了各个更新周期并对其进行了编号。如您所见，第二次更新有明显的延迟（黄色）。

在黄色期间，没有其他线程在工作（至少根据分析器）。当一一选择线程时，除一个之外的所有线程都不在执行操作。正如您在下一张图片中看到的那样，仍在执行操作的一个线程没有显示任何 CPU 负载，并且所有时间都花在ntdll.dll.

在这种情况下，调用GetEnumerator大约需要 24 毫秒，但我也看到过类似ToString()或类似的函数冻结ToArray()。

我观察到的相关内容：

• 冻结与特定功能无关，可能发生在应用程序的任何部分
• 花费的时间总是显示在ntdll.dll
• 通常发生在 GC 之后
• 在分析时间运行的所有 GC 都是 gen0
• 被调用函数分配内存

我有一条奇怪的错误消息，在开始分析远程进程时系统性地出现

通过 dotTrace 并且仅在时间线模式下发生。

无法继续分析：磁盘已满 需要启动命令确认：未知错误 (hresult_error:ADAB0005) [位置] = C:\BuildAgent\work\d843735b9e94e41c\Profiler\Kernel\Windows\Native\Solution\core\src\bridges\etw \etw_bridge.cpp(281) [函数] = void __thiscall jbprof::etw_bridge::start(struct jbprof::snapshot_iface *)

我已经为 IIS 服务器中托管的网站设置了 dotTrace。当 JetBrains dotTrace 启动时，IIS 网站运行良好并且配置文件启动。完成配置文件后，IIS 网站未加载，并且似乎被 dotTrace 锁定。该网站无法从 IIS 服务器启动。

如果 JetBrains dotTrace 再次开始运行，该网站将再次开始运行。这似乎与 IIS 网络服务器相关的一些服务被 dotTrace 锁定。

请看一下这个问题。

我正在尝试使用 JetBrains Profiler API (JetBrains.Profiler.Api 1.1.8) 来分析一种方法。工作流程是：

• 启动程序
• 让应用程序达到我想要分析的程度
• 启动 dotTrace 并使用以下设置启动它
• 
• 分析任务栏显示会话正在运行

我已经尝试了以下两个代码片段

该方法执行，但我无法在磁盘或 dotTrace 快照中的任何位置看到快照。我错过了什么？

在分析使用async/awaitdotTrace 功能的应用程序时，我注意到await父方法和子方法在时间上存在一些不一致。让我们考虑这个例子：

有趣的是，方法的await时间Main可能（甚至会）比我觉得奇怪的时间要少，因为直觉上await父母的时间应该至少和孩子的时间一样。ChildMethodawaitawait

对于实数，让我们回到前面的例子并假设SomeOperationAsync是Task.Delay(n)。因此，await父级的时间将是（x针对面向 .NET 6.0的应用程序和针对 .NET Core 3.1 的应用程序），子级的时间将是。x~n<nawait~2*x

这是来自 dotTrace 的屏幕截图，用于了解它的外观（针对面向 .NET Core 3.1 的应用程序和针对 .NET Core 3.1 的应用程序Task.Delay(800)）：

1. 这是await方法的时候Main。567ms，await ChildMethod()我希望是这样~800，因为 ChildMethod等待Task.Delay(800)
2. 这是await方法的时候ChildMethod。为1140 毫秒await Task.Delay(800)。我也希望是这样~800。

可能我误解了awaitdotTrace 中的时间，所以如果是，请纠正我。我将其理解为安排任务所需的时间 + 实际任务执行。

如果有人知道这种行为是否是预期的并且可以解释如何分析它，那就太好了。

我在 dotTrace 2021.3.3 中使用时间线查看器。

更新

我想我理解我困惑的第一部分，即为什么 等待 时间小于方法中传递的Task.Delay时间Main。这是因为任务的计时器比继续附加（内部调用AwaitUnsafeOnCompleted）更早开始，因此它只等待剩余时间。就我而言，此调用大约需要300 毫秒，因此await时间变为time passed to Task.Delay - time spent on attaching continuation.