张店网站设计,网店运营推广高级实训攻略,在线代理网页服务器,凡科互动下载编者按#xff1a;即使.NET Core3.1.5已经发布#xff0c;在进行.NET Core的性能诊断时#xff0c;我们有时依然不知该从何处下手#xff0c;那这篇介绍.NET Core3.0中引入的诊断工具#xff0c;或许能为我们提供参考。在.NET Core 3.0中#xff0c;我们引入了一套工具即使.NET Core3.1.5已经发布在进行.NET Core的性能诊断时我们有时依然不知该从何处下手那这篇介绍.NET Core3.0中引入的诊断工具或许能为我们提供参考。在.NET Core 3.0中我们引入了一套工具这些工具利用了.NET运行时中的新功能使诊断和解决性能问题变得更加容易。这些运行时功能可帮助您回答一些常见的诊断问题我的应用程序健康吗为什么我的应用程序有异常行为为什么我的应用程序崩溃了我的应用程序健康吗通常应用程序可能会慢慢开始泄漏内存并最终导致内存不足异常。在其他时候某些有问题的代码路径可能会导致CPU使用率激增。这些只是您可以通过指标主动识别的一些问题类别。指标指标表示一段时间内的数据量度。指标(或时间序列)数据使您可以从高层次观察系统状态。与Windows上的.NET Framework不同.NET Core不会发出性能计数器。相反我们引入了一种通过EventCounter API 在.NET Core中发出指标的新方法。EventCounters提供了Windows性能计数器的改进因为这些计数器现在可在支持.NET Core的所有操作系统上使用。此外与perf计数器不同它们还可以在低特权环境(例如xcopy部署)中使用。不幸的是由于缺少诸如性能监视器(perfmon)之类的工具因此很难实时使用这些指标。dotnet-counters在3.0-preview5中我们引入了一个新的命令行工具用于实时观察.NET Core应用程序发出的指标。您可以通过运行以下命令来安装此.NET全局工具dotnet tool install --global dotnet-counters --version 1.0.3-preview5.19251.2在下面的示例中当我们将负载生成器指向Web应用程序时我们看到应用程序的CPU利用率和工作集内存急剧上升。有关如何使用此工具的详细说明请参阅dotnet-counters自述文件。对于已知的限制请查看GitHub上的未解决问题。dotnet-counters为什么我的应用程序有异常行为虽然指标可以帮助识别异常行为的发生但它们几乎无法提供问题的可见性。要回答为什么您的应用程序具有异常行为的问题您需要通过跟踪收集其他信息。例如通过跟踪收集的CPU配置文件可以帮助您识别代码中的热路径。追踪跟踪是离散事件的不加时间戳的记录。跟踪包含本地上下文可让您更好地推断系统的命运。传统上.NET Framework(以及ASP.NET等框架)通过Windows事件跟踪(ETW)发出有关其内部的诊断跟踪。在.NET Core中这些跟踪被写入Windows上的ETW和Linux上的LTTng。dotnet-trace在3.0-preview5中每个.NET Core应用程序都会打开一个双工管道EventPipe(该管道可以在其上发出事件)(在* nix上是Unix域套接字/在Windows上是一个命名管道)。当我们仍在研究控制器协议时请实现此协议的预览版。dotnet-trace您可以通过运行以下命令来安装此.NET全局工具dotnet tool install --global dotnet-trace--version 1.0.3-preview5.19251.2在上面的示例中我dotnet trace使用默认配置文件运行该配置文件启用了CPU事件探查器事件和.NET运行时事件。除了默认事件之外您还可以根据要尝试执行的调查来启用其他提供程序。运行后dotnet trace将显示一个.netperf文件。该文件包含运行时事件和可以在perfview中显示的示例 CPU堆栈。Visual Studio的下一个更新(16.1)也将添加对可视化这些跟踪的支持。如果捕获跟踪时在OS X或Linux上运行则可以选择将这些.netperf文件转换为可以使用Speedscope.app可视化的.speedscope.json文件。您可以通过运行以下命令来转换现有跟踪dotnet trace convert input-netperf-file下图显示了冰柱图可视化了我们刚刚在Speedscope中捕获的轨迹。有关如何使用此工具的详细说明请参阅dotnet-trace自述文件。对于已知的限制请查看GitHub上的未解决问题。dotnet-trace为什么我的应用程序崩溃了在某些情况下仅通过跟踪过程就不可能确定导致异常行为的原因。如果流程崩溃或我们可能需要更多信息(例如访问整个流程堆)的情况则流程转储可能更适合分析。转储分析转储是通常在进程意外终止时捕获的进程的工作虚拟内存状态的记录。诊断核心转储通常用于确定应用程序崩溃或意外行为的原因。传统上您在应用程序崩溃时依靠操作系统来捕获转储(例如Windows错误报告)或者在满足某些触发条件时使用procdump之类的工具来捕获转储。迄今为止在Linux上使用.NET捕获转储的挑战是使用NET捕获转储gcore否则调试器会导致极大的转储因为现有工具不知道在.NET Core进程中要修剪哪些虚拟内存页。此外即使您已经收集了这些转储也仍然需要分析调试器因为它需要获取调试器并将其配置为加载sos(.NET的调试器扩展)这具有挑战性。dotnet-dump3.0.0-preview5我们引入了一个新工具使您可以捕获和分析Windows和Linux上的进程转储。dotnet-dump 仍在积极开发中下表显示了哪些操作系统当前支持哪些功能。视窗OS X的Linux收集✅❌✅分析❌❌✅您可以通过运行以下命令来安装此.NET全局工具dotnet tool install --global dotnet-dump --version 1.0.3-preview5.19251.2安装完成后您可以通过运行以下命令来捕获进程转储dotnet dumpsudo $HOME/.dotnet/tools/dotnet-dump collect -p 在Linux上可以通过运行以下命令加载结果转储来分析结果转储dotnet dump analyze dump-name在下面的示例中我尝试通过遍历堆来确定崩溃转储的ASP.NET Core宿主环境。有关如何使用此工具的详细说明请参阅dotnet-dump自述文件。对于已知的dotnet-dump限制请查看GitHub上的未解决问题。
