内容简介：原文：Sourabh Shirhatti翻译：Edi Wang在 .NET Core 3.0 中，我们将引入一套工具，这些工具利用 .NET 运行时中的新功能，使诊断和解决性能问题变得更加容易。
原文：Sourabh Shirhatti
翻译：Edi Wang
在 .NET Core 3.0 中，我们将引入一套工具，这些 工具 利用 .NET 运行时中的新功能，使诊断和解决性能问题变得更加容易。
这些运行时功能可帮助您回答一些常见的诊断问题：
-
我的应用程序是否正常？
-
为什么我的应用程序有异常行为？
-
为什么我的应用程序崩溃？
我的应用程序是否正常?
通常，应用程序可能会缓慢地开始泄漏内存，并最终导致内存不足异常。其他时候，某些有问题的代码路径可能会导致 CPU 利用率激增。这些只是您可以主动根据 Metrics （指标）识别出的一类问题。
Metrics（指标）
指标是时间间隔内数据度量的表示形式。指标(或时间序列)数据允许您在高级别上观察系统的状态。与 Windows 上的 .NET Framework不同，.NET Core不会产生 perf 计数器。相反，我们引入了一种通过EventCounter API 在 .NET Core 中发出指标的新方法。
EventCounter提供了对 Windows perf 计数器的改进，因为这些计数器现在可用于支持 .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-counter readme （https://github.com/dotnet/diagnostics/blob/master/documentation/dotnet-counters-instructions.md）。
有关dotnet-counter的已知限制，请查看 GitHub 上的未解决的问题（https://github.com/dotnet/diagnostics/issues?q=is%3Aopen+is%3Aissue+label%3Adotnet-counters）。
为什么我的应用程序有异常行为?
虽然指标有助于识别异常行为的发生，但它们对出错的原因几乎无法了解。要回答应用程序为何出现异常行为的问题，您需要通过跟踪（traces）收集其他信息。例如，通过跟踪收集的 CPU 配置文件可以帮助您识别代码中的热点路径。
Tracing （跟踪）
跟踪是不可变离散事件的时戳记录。跟踪包含本地上下文，允许您更好地推断系统的命运。传统上，.NET Framework (以及ASP.NET等框架)通过 Windows 事件跟踪 (ETW) 发出有关其内部的诊断跟踪。在 .NET Core中，这些跟踪写入了 Windows 上的 ETW 和 Linux 上的 LTTng。
dotnet-trace
在 3.0-preview5 中，每个 .NET Core 应用程序都会打开一个名为 EventPipe 的双工管道(Windows 上的Unix域套接字*nix/named管道)，它可以在其上发出事件。当我们仍在研究控制器协议时，dotnet-trace实现了此协议的预览版本。
您可以通过运行以下命令来安装此 .NET 全局工具：
dotnet tool install --global dotnet-trace--version 1.0.3-preview5.19251.2
（译者注：由于平台限制，无法嵌入视频，请阅读原文查看以上工具的屏幕录像）
在上面的示例中，我使用启用 CPU 探查器事件和 .NET 运行时事件的默认配置文件运行 dotnet-trace。
除了默认事件之外，还可以根据尝试执行的调查启用其他提供程序。
因为运行了 dotnet-trace，您会得到一个 .netperf 文件。此文件包含运行时事件和可按视图可视化的采样 CPU 堆栈。Visual Studio (16.1) 的下一次更新还将添加对这些跟踪可视化的支持。
如果在捕获跟踪时在 OS X 或 Linux 上运行，则可以选择将这些 .netperf 文件转换为 .speedscope.json 文件，这些文件可以通过 Speedscope.app 进行可视化。
您可以通过运行以下命令来转换现有跟踪文件：
dotnet trace convert
下面的冰柱图可视化了我们刚刚在speedscope里捕获的追踪：
有关如何使用此工具的详细说明，请查看 dotnet-trace readme（https://github.com/dotnet/diagnostics/blob/master/documentation/dotnet-trace-instructions.md）。有关dotnet-trace的已知限制，请查看 GitHub 上的未解决问题（https://github.com/dotnet/diagnostics/issues?q=is%3Aopen+is%3Aissue+label%3Adotnet-trace）。
为什么我的应用程序会爆?
在某些情况下，仅通过跟踪进程就无法确定导致异常行为的原因。如果进程崩溃或可能需要更多信息(如访问整个流程堆)的情况，则进程转储可能更适合分析。
转储分析（Dump Analysis）
转储是进程意外终止时通常捕获的进程的工作虚拟内存状态的记录。诊断核心转储文件通常用于识别应用程序崩溃或意外行为的原因。
传统上，您依靠操作系统在应用程序崩溃(例如Windows 错误报告)时捕获转储，或者使用 procdump 等工具在满足某些触发条件时捕获转储。
到目前为止,在 Linux 上使用 .NET 捕获转储的挑战是使用 gcore 或调试器捕获转储，导致转储非常大，因为现有工具不知道在 .NET Core 进程中要修剪哪些虚拟内存页。
此外，即使收集了这些转储，也难以分析这些转储，因为它需要获取调试器并将其配置为加载 sos，这是 .NET 的调试器扩展。
dotnet-dump
3.0.0-preview5中，我们引入了一个新的工具，允许您捕获和分析 Windows 和 Linux 上的进程转储。
dotnet-dump 仍处于活跃开发状态，下表显示了当前在哪些操作系统上支持的功能。
您可以通过运行以下命令来安装此 .NET 全局工具：
dotnet tool install --global dotnet-dump --version 1.0.3-preview5.19251.2
安装 dotnet-dump后，可以通过运行以下命令来捕获进程转储：
sudo $HOME/.dotnet/tools/dotnet-dump collect -p
在 Linux 上，可以通过运行以下命令加载生成的转储来分析生成的转储：
dotnet dump analyze
在下面的示例中，我尝试通过遍历堆来确定已崩溃转储ASP.NET Core托管环境。
（译者注：由于平台限制，无法嵌入视频，请阅读原文查看以上工具的屏幕录像）
感谢您在 .NET Core 3.0 中尝试新的诊断工具。请继续向我们提供反馈，无论是在评论中还是在 GitHub 上。我们正在认真倾听，并将继续根据您的反馈进行更改。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
微信小程序运营与推广完全自学手册
王洪波 / 电子工业出版社 / 2018-6 / 59
本书是运营管理方面的书籍，将小程序的运营推广问题置千小程序的整个运营管理体系中来谈，主要讲述小程序的定位规划、营销吸粉策略、评估优化这三大方面的内容，这三方面的内容之间是三位一体、密切相关的。 书中通过列举丰富且具有代表性的小程序实际案例来向读者提供些可行的运营推广办法。案例涉及美食类、电商类、旅游类、媒体类等小程序，可供多个行业的小程序运营者参考借鉴。 书中所提供的各种小程序营销策略......一起来看看 《微信小程序运营与推广完全自学手册》 这本书的介绍吧!
