通过

实验室 2.2 在 Linux 中使用 ProcDump 捕获转储文件

适用于： .NET Core 2.1、.NET Core 3.1、.NET 5

本文讨论 ProcDump 工具的安装，以及如何在 Linux 中使用 ProcDump 捕获 .NET Core 内存转储文件。

先决条件

遵循以下故障排除实验室的最低要求如下：

  • ASP.NET 核心应用程序，用于演示低 CPU 和高 CPU 性能问题和崩溃问题。
  • 打开核心转储文件时，lldb 调试器已安装并配置为加载 SOS 扩展。

如果已遵循本系列的上一部分，则应准备好进行以下设置：

  • Nginx 配置为托管两个网站：
    • 第一个使用 myfirstwebsite 主机标头 （http://myfirstwebsite） 侦听请求，并将请求路由到在端口 5000 上侦听的演示 ASP.NET Core 应用程序。
    • 第二个使用 buggyamb 主机标头 （http://buggyamb） 侦听请求，并将请求路由到侦听端口 5001 的第二个 ASP.NET 核心示例 buggy 应用程序。
  • ASP.NET Core 应用程序应作为服务运行，这些服务会在服务器重启或应用程序停止响应时自动重启。
  • Linux 本地防火墙已启用并配置为允许 SSH 和 HTTP 流量。

注意

如果设置尚未准备就绪，请转到“第 2 部分创建并运行 ASP.NET Core 应用”。

本实验室的目标

在前面的实验室中，你了解了如何分析崩溃或性能问题。 你已使用 createdump 工具捕获转储文件。

现在，你将安装 ProcDump，并使用 ProcDump 捕获核心转储文件。 这将是本实验室的范围，因为你将在上一部分中调查的同一方案中工作。

ProcDump

根据 Linux 版本的 ProcDump 的官方页面，“ProcDump 是 Windows 工具套件中经典 ProcDump 工具的 Linux 重新映像。

与 Windows 版本相比，Linux 版本存在一些限制。 它不支持 Windows 版工具提供的每个功能。 例如，当进程崩溃或引发第一次机会异常时，无法将其配置为收集核心转储文件。

然而，它仍然强大。 以下命令行选项列表在证明工具强度方面有很长的路要走：

-C: Trigger core dump generation when CPU exceeds or equals specified value (0 to 100 * nCPU)
-c: Trigger core dump generation when CPU is less than specified value (0 to 100 * nCPU)
-M: Trigger core dump generation when memory commit limit exceeds or equals specified value (MB)
-m: Trigger core dump generation when memory commit limit is less than specified value (MB)
-T: Trigger core dump generation when thread count exceeds or equals specified value.
-F: Trigger core dump generation when filedescriptor count exceeds or equals specified value.

安装 ProcDump 上详细介绍了安装说明。 回想一下，在安装 .NET Core 之前，已指示添加Microsoft包存储库。 ProcDump 使用相同的存储库。 因此，可以使用命令直接安装该工具 sudo apt install procdump 。

sudo apt install procdump 命令的屏幕截图。

可以使用 ProcDump 监视 CPU、内存、线程或文件描述符使用情况。

当目标进程 CPU 或内存使用率达到特定阈值或低于限制值时，可以使用 ProcDump 捕获内存转储文件。 但是，在本练习中，你将使用最简单的方法来调用该工具： procdump -p <PID> 这会手动创建进程的转储文件。

捕获同一进程的内存转储文件。 请注意，必须使用以下命令来运行命令 sudo。

sudo procdump 命令的屏幕截图。

ProcDump 在何处创建核心转储文件？

这是你当然必须知道的信息。 在 ProcDump 用于捕获核心转储文件时，可以花大量时间尝试了解创建转储文件的位置。

ProcDump 输出不清楚核心转储文件的创建位置。 如上一屏幕截图所示，输出只写入文件的名称，但不会写入实际路径。

由于其他工具通常使用 /tmp/ 或 /var/lib/systemd/coredump/ 目录，因此你可能会认为 ProcDump 也使用这些目录之一。 但是，情况并非如此。 而是在 ASP.NET Core 应用程序工作目录中创建 ProcDump 捕获的转储文件。

应用程序的工作目录在服务控制单元文件中定义。 如以下屏幕截图所示，示例应用程序的工作目录为 /var/BuggyAmb_v1.1。 因此，ProcDump 为此应用程序创建的任何转储文件都将放入 /var/BuggyAmb_v1.1 目录中。

cat 和 ll 命令的屏幕截图。

示例方案：基于内存使用情况捕获转储文件

假设出现了下面这种情景：

  • 在托管的 ASP.NET Core 应用程序上遇到高内存消耗。
  • 高内存消耗随机发生，你不知道如何重现问题。 仅知道当承载应用程序的进程提交内存使用率达到 750 MB 时，问题才会开始。
  • 由于无法持续监视内存使用情况，因此需要自动执行转储收集过程。 目标是在内存使用量超过 750 MB 阈值后捕获同一进程的两个连续转储文件。
  • 你想要捕获两个内存转储文件，第一个和第二个内存转储文件的生成间隔至少为 5 秒。

根据 ProcDump 帮助，以下是必须使用的开关：

  • -M：当内存提交超过或等于指定值时触发核心转储文件生成（MB）
  • -n：退出前要写入的核心转储文件数（默认值为 1）
  • -s：写入转储文件之前的连续秒（默认值为 10）
  • -d：将诊断日志写入 Syslog
  • -p：进程的 PID

运行 sudo procdump -p 11724 -n 2 -s 5 -M 750 命令。 你将看到 ProcDump 等待，直到满足传递给它的自变量定义的条件，或者直到你决定通过按 Ctrl+C 结束监视阶段。

sudo procdump p 命令的屏幕截图。

虽然 ProcDump 正在监视内存使用情况，但通过再次使用 Load Generator Web 应用程序的功能向慢速方案发送六个请求来重现相同的问题。 内存使用率达到阈值后，ProcDump 会创建转储文件。 以下屏幕截图显示了两个捕获的转储文件。

sudo procdump p n 命令的屏幕截图。

转储文件写入工作目录中，与之前创建的手动内存转储文件的情况相同。

ls 命令的屏幕截图。

使用 createdump 和 ProcDump 创建的转储文件在包含的信息方面是相同的。 你可以选择你认为最适合解决此类问题时遇到的方案的工具。

后续步骤

实验室 3 排查 Linux 中 dotnet-dump 的性能和 GC 问题

实验室 3 讨论使用和dotnet-gcdump处理内存转储文件dotnet-dump的其他选项。

  • Last updated on