使用 SOS 对 Linux 中运行的 .NET Core 进行问题诊断

目录

• 说明
• 准备一个方便的学习环境
  • 2.x 配置内容
  • 3.x 配置内容
• 工具介绍
  • lldb sos plugin
    • 1. attach 到进程上进行调试
    • 2. 分析core dump文件
  • SOS
• 案例分析
  • CPU 占用过高
  • 内存泄漏
  • Monitor导致的死锁
• .NET Core 3.x 的不同点
  • dotnet-sos
  • dotnet-dump
• 如何将 createdump 创建的 coredump 文件转移到其他位置分析
• 如何将 dotnet-dump 创建的 coredump 文件转移到其他位置分析

说明

• 本文主要描述 Linux 环境下 .NET Core 程序的问题分析方案，也会提及如何将 Linux 系统中保存好的 core dump 文件转移到其他位置进行分析，Mac 环境中未尝试成功，Windows 中推荐使用 WSL。
• 将依次讲解如何在 .NET Core 2.x、.NET Core 3.x、.NET 5.x 中使用 SOS 命令。.NET Core 3.x 与 .NET 5.x 一致，以.NET 3.x 为例。
• .NET Core 2.x 的例子中使用 plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/运行时版本号/libsosplugin.so 的方式加载 SOS 插件。.NET Core 3.x 开始提供了 dotnet-sos 来实现自动加载。且可以直接在.NET Core 2.x 环境中用 dotnet tool 安装到，后面也会讲到具体的操作。
• 进行 dump 的 Linux 环境必须开启 SYS_PTRACE。

准备一个方便的学习环境

为了方便我们的学习，我们可以准备一下 Linux 的开发测试环境，借助 VS Code 的 Remote Containers 功能可以很方便的构建出纯净的 Linux 测试环境。这里需要确保 Docker 运行正常。

如果不需要通过此方式构建环境，可以直接跳到下一节。

• 安装 VS Code 插件 Remote - Containers
  
  
• 创建一个文件夹并用 VS Code 打开，在该文件夹下创建下列文件结构

工作目录
└── .devcontainer
    ├── devcontainer.json
    ├── docker-compose.yml
    └── Dockerfile

2.x 配置内容

devcontainer.json

{
	"name": ".NET Core 2.x",
	"dockerComposeFile": "docker-compose.yml",
	"service": "dotnet-core-2.x", // 名字要和 docker-compose.yml 中定义的 service 名字一致
	"workspaceFolder": "/workspace",
	"settings": {
		"terminal.integrated.shell.linux": "/bin/bash"
	},
	"extensions": ["ms-dotnettools.csharp"] // 安装容器中 VS Code Server 的 C# 插件
}

docker-compose.yml

version: '3'
services:
 dotnet-core-2.x:
   build:
     context: .
     dockerfile: Dockerfile

   volumes:
     # 把 VS Code 的工作目录挂载到容器的 workspace 目录下
     - .:/workspace:cached

   # 需要开启 SYS_PTRACE 的配置
   cap_add:
     - SYS_PTRACE

   # 避免容器主进程执行结束而退出
   command: /bin/sh -c "while sleep 1000; do :; done"

Dockerfile

FROM microsoft/dotnet:2.1.300-sdk
# 直接写入阿里源，方便 lldb 等工具的下载
RUN echo "deb http://mirrors.aliyun.com/debian/ stretch main non-free contrib\n\
deb-src http://mirrors.aliyun.com/debian/ stretch main non-free contrib\n\
deb http://mirrors.aliyun.com/debian-security stretch/updates main\n\
deb-src http://mirrors.aliyun.com/debian-security stretch/updates main\n\
deb http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib\n\
deb-src http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib\n\
deb http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib\n\
deb-src http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib"\
> /etc/apt/sources.list
# 安装在镜像内，避免下次用的时候重复安装
RUN apt update && apt install -y lldb-3.9

3.x 配置内容

devcontainer.json

{
	"name": ".NET Core 3.x",
	"dockerComposeFile": "docker-compose.yml",
	"service": "dotnet-core-3.x",
	"workspaceFolder": "/workspace",
	"settings": {
		"terminal.integrated.shell.linux": "/bin/bash"
	},
	"extensions": ["ms-dotnettools.csharp"]
}

docker-compose.yml

version: '3'
services:
 dotnet-core-3.x:
   build:
     context: .
     dockerfile: Dockerfile

   volumes:
     # 把 VS Code 的工作目录挂载到容器的 workspace 目录下
     - .:/workspace:cached

   # 后面需要使用 基于 ptrace 的 lldb，这里需要开启 SYS_PTRACE 的配置
   cap_add:
     - SYS_PTRACE

   # 避免容器主进程执行结束而退出
   command: /bin/sh -c "while sleep 1000; do :; done"

Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:3.1
# 把所有后面可能会用到工具都提前装好
RUN dotnet tool install --global dotnet-counters &&\
dotnet tool install -g dotnet-dump &&\
dotnet tool install -g dotnet-gcdump &&\
dotnet tool install --global dotnet-trace &&\
dotnet tool install -g dotnet-symbol &&\
dotnet tool install -g dotnet-sos
# 将上述工具所在的文件夹添加到 PATH
ENV PATH /root/.dotnet/tools:$PATH
# 替换成阿里源
RUN echo "deb http://mirrors.aliyun.com/debian/ buster main non-free contrib\n\
deb-src http://mirrors.aliyun.com/debian/ buster main non-free contrib\n\
deb http://mirrors.aliyun.com/debian-security buster/updates main\n\
deb-src http://mirrors.aliyun.com/debian-security buster/updates main\n\
deb http://mirrors.aliyun.com/debian/ buster-updates main non-free contrib\n\
deb-src http://mirrors.aliyun.com/debian/ buster-updates main non-free contrib\n\
deb http://mirrors.aliyun.com/debian/ buster-backports main non-free contrib\n\
deb-src http://mirrors.aliyun.com/debian/ buster-backports main non-free contrib"\
> /etc/apt/sources.list

在完成了 Remote - Containers 插件的安装 并完成了上述三个文件的配置之后。

直接通过 VS Code 左下角的按钮在自动构建的容器中打开工作目录。



完成之后，我们就拥有了一个自由玩耍的空间了。

可以直接在里面写代码或者把写好的代码拖到 VS Code 工作目录中。

工具介绍

lldb sos plugin

lldb 是一个软件调试器，支持 C/C++ 的调试和 Linux core dump 文件的分析。

微软提供了 lldb 的 SOS(Son of Strike) 插件，可以通过这个插件获取运行时的线程，托管堆中的对象等信息。

官方推荐使用的 lldb 版本是 3.9 到 9。实测 3.8 版本有问题，会无法查看 thread 的 stack 信息。

Ubuntu/Debian安装方式 apt install lldb-3.9。

.NET Core 2.x 版本中，SOS 插件直接在 .NET Core 的安装目录中可以找到，不强依赖 sdk，runtime 中也是自带的。

/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.0/libsosplugin.so

其中 2.1.0 是版本号，需根据实际的 dotnet runtime 版本号（通过 dotnet --info 获取信息）进行替换。

一共有两种使用方式：

1. attach 到进程上进行调试

lldb-3.9 dotnet -p 进程号 -o "plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/运行时版本号/libsosplugin.so"

注意：这种方式会停掉进程。如果是线上服务，使用请慎重，最好先下掉流量。

等效 lldb-3.9 dotnet -p 进程号 再在lldb cli内执行 plugin load 插件路径。

2. 分析core dump文件

首先我们需要得到 dotnet 程序的 core dump 文件。创建 dump 文件的方式有很多。最简单可以使用 dotnet runtime 中自带的 createdump 工具。

/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.0/createdump 进程id

创建 dump 的同时，进程会短暂暂停，完成 dump 后恢复运行。文件的大小取决于应用所占内存的大小。这样我们就可以得到了 coredump 文件。

针对线上环境，有条件的同学可以直接在线上环境内分析，如果你的容器配置不是很高，是在一个短暂存活的 k8s pod中，建议下到本地进行分析，如果文件过大，传输过程中建议先压缩。

加载 dump 文件的方式如如下：

lldb-3.9 dotnet -c dump文件路径 -o "plugin load 插件路径"

SOS

无论使用上面哪种方式，接下来操作都是一样的，使用 lldb 的命令以及 sos 的扩展

soshelp 可以看到所有支持的 sos 命令。点击跳转官方文档

soshelp <functionname> 可以看到每种命令具体的使用方式

使用 sos 完整命令名字 或者直接使用 别名

案例分析

无论是采取的 attach 到进程的方式，还是分析 core dump 文件的方式。最后都会进入一样 lldb cli 界面。接下来伴随实际的案例介绍一个新朋友，sos 指令。

CPU 占用过高

测试代码

[Route("api/[controller]")]
public class TestController : ControllerBase
{
    [HttpGet("highcpu/{milliseconds}")]
    public string HighCpu(int milliseconds)
    {
        var sw = Stopwatch.StartNew();
        while (true)
        {
            sw.Stop();
            if (sw.ElapsedMilliseconds > milliseconds) break;
            sw.Start();
        }
        return "success:highcpu";
    }
}

使用 ps 进行线上问题可能性排查。

注意：这一步是一定要做的，否则后面没办法定位具有问题的线程。

ps [options] [--help]

options:

• a 显示现行终端机下的所有程序，包括其他用户的程序。
• u 以用户为主的格式来显示程序状况。
• x 显示所有程序，不以终端机来区分。
• -T 以线程维度展示。

精简版镜像可能没有 ps 工具。可自行安装，如 apt install procps。

实际进程可能比较多，可以加上 grep dotnet 进行过滤



其中 ps aux -T | head -n1 是为了保留标题行

关键列说明：

• PID: 进程ID
• SPID: 线程ID
• %CPU: CPU使用率
• TIME: 运行时间

可以看到，我们的应用进程ID是 1069，问题线程ID为 1709，102%CPU。

利用上文所述的两种方式之一进入 lldb cli。

如果使用 createdump 的方式，一定要加上 -u 进行全量的dump，否则线程栈信息不全，影响问题分析。

/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.0/createdump -u 1069

1. clrthreads 指令查看概览托管线程的信息。



2. thread select 线程编号 选中线程，或者使用简化指令 t 线程编号

我们需要注意上图圈红的那两列，其中 OSID 是用 16进制 表示的操作系统的线程编号，1709（10进制）等于 6ad（16进制）。需要通过一次换算来在 clrthreads 的结果中匹配 ps 找到的线程。

thread select 后面跟的参数是第一列，而非 ID 那一列。

6ad 对应的第一列线程编号 21，所以执行 thread select 21 或者 t 21。



3. clrstack 查看选中线程的调用栈 栈帧确定线程执行的内容。

• Child SP: Thread Stack Poiner
• IP Call Site: Instruction Pointer Call Site
  
  从而，可以定位到问题代码

内存泄漏

使用 attach 或者 core dump 方式进行分析。createdump 也需要全量。

排查内存问题，我们需要用到 dumpheap 指令。

dumpheap [options]

常用 options:

• -stat –只输出堆上所有类型对象的统计摘要，它们的数量和它们自身的大小（不含引用）。
• -min 最小大小，单位 byte。
• -max 最大大小，单位 byte。
• -mt 根据 MethodTable 地址过滤对象。
• -type 类型名和给定的字符串部分匹配的类型的所有实例对象。

MethodTable 是 CLR 中维护类型方法信息等原数据的重要数据结构。和类型是一一对应的关系。

测试代码

[Route("api/[controller]")]
public class TestController : ControllerBase
{
    private static ConcurrentBag<MemoryLeak> _cache = new ConcurrentBag<MemoryLeak>();

    [HttpGet("memoryleak/{count}")]
    public string MemoryLeak(int count)
    {
        for (int i = 0; i < count; i++)
        {
            _cache.Add(new MemoryLeak());
        }
        return "success:memoryleak";
    }
}

public class MemoryLeak
{
    private byte[] _data;
    public MemoryLeak()
    {
        _data = new byte[1024];
    }
}

1. 分析什么类型的对象占的内存最大



-stat 是为了只看摘要信息。

占内存最大的是 MemoryLeak[] 类型的实例。

如果你能够根据该类型定位到是哪块代码出了问题，那我们的故事就到此结束了。不是的话就要注意到这个线索 MemoryLeak 的 MethodTable 地址为 00007fb64b1e4488。

2. dumpheap -mt <address> 根据 MethodTable 找到有问题的对象的地址。取其中一个对象的地址。如 00007fb5d8042c68。



3. gcroot <address> 找到可能存在内存泄漏的根



如果能从上面的引用链上能找到能定位问题的地方，那故事也到此结束。如我们可以看到内存泄漏是发生在一个 Concurrent.ConcurrentBag<Test2.x.Controllers.MemoryLeak> 类型的容器上的。

4. 寻找静态字段所在的类型（暂未解决）

pinned handle 表示这是一个静态字段。那么怎么去定位这个静态字段所在的类呢。本人能力有限，仅找到了一篇 windbg 的老文章，暂时不知道 lldb 中如何操作。

https://dlaa.me/blog/post/9471347

Monitor导致的死锁

测试代码

class Program
{
    private static readonly object LockObj1 = new object();
    private static readonly object LockObj2 = new object();

    static void Main(string[] args)
    {
        Method1();
        Method2();
        Console.ReadLine();
    }

    static void Method1()
    {
        Task.Run(() =>
        {
            lock (LockObj1)
            {
                Thread.Sleep(1000);
                lock (LockObj2)
                {
                    Console.WriteLine("Hello World Method1");
                }
            }
        });
    }

    static void Method2()
    {
        Task.Run(() =>
        {
            lock (LockObj2)
            {
                Thread.Sleep(1000);
                lock (LockObj1)
                {
                    Console.WriteLine("Hello World Method2");
                }
            }
        });
    }
}

执行这段代码后没有任何结果输出。

1. 利用 clrthreads，Lock Count 1 表示正在等待一个 Monitor 锁。这个数字也就是线程持有的同步块数量。除去第一个是 Console.ReadLine() 中的锁。另外两个标识着 Threadpool Worker 的的线程就是上面代码死锁的两个线程。



2. 选中线程，用 clrstack 查看当前线程执行的内容从而定位到问题。

.NET Core 3.x 的不同点

3.x 开始提供了一套诊断工具。

• dotnet-sos
  
  使用 lldb 时会自动加载 sos 插件, createdump 在 3.1 下依旧存在
• dotnet-dump
  
  在不涉及本机调试的情况下收集和分析托管代码相关的 dump，可以运行在 lldb 无法正常运行的平台
• dotnet-gcdump
  
  基于 EventPipe 收集实时 .NET 进程的 GC 信息
• dotnet-counters
  
  基于 EventCounter API 发布的 Metrics 快速定位问题的临时性监控工具
• dotnet-trace
  
  基于 EventPipe 收集 正在运行的进程中收集信息
• dotnet-symbol
  
  在其他地方分析 dump 文件时，需要下载对应的 symbol 文件

本文只介绍和 SOS 相关的部分。

dotnet-sos

dotnet 安装目录中不再包含 libsosplugin.so。取而代之的是 dotnet-sos。

安装完毕后，每次使用lldb都会自动加载sos 插件。

也可以用于 .NET Core 2.x。

安装方式

dotnet tool install –g dotnet-sos
dotnet-sos install

如果 dotnet-sos 安装目录的环境变量没有设置成功，需要到对应目录下进行安装

用户home目录/.dotnet/tools/dotnet-sos install

在新的sos插件中也增加了一些新的 sos 命令，例如 syncblk。



分析之前的那个 Monitor 死锁的 core dump，得到持有同步块的线程 id

dotnet-dump

dotnet-dump 的出现并不是为了完全取代上面一直在用的 lldb，它只能查看托管代码相关的信息。

且不能用 .NET Core 2.x。

dotnet-dump ps

查看 dotnet-dump 能够进行分析的进程

dotnet-dump collect [-p] [--type] [-o]

• -p 进程ID

• --type <Full|Heap|Mini> 指定转储类型，它确定从进程收集的信息的类型。 有三种类型：
  
  Full - 最大的转储，包含所有内存（包括模块映像）。
  
  Heap - 大型且相对全面的转储，其中包含模块列表、线程列表、所有堆栈、异常信息、句柄信息和除映射图像以外的所有内存。
  
  Mini - 小型转储，其中包含模块列表、线程列表、异常信息和所有堆栈。
  
  如果未指定，则 Full 为默认类型。

• -o dump 保存路径，如果没有指定，默认当前路径
  
  

dotnet-dump analyze <dump_path>

进入之后，一样可以用到之前提到的那些 sos 命令

因为没有 lldb 的 thread select <tid> 命令可以切换线程，需要使用 setthread

如何将 createdump 创建的 coredump 文件转移到其他位置分析

上面分析 coredump 文件的例子都是直接在现场分析的。但实际情况中，我们可能会选择将文件从服务器中保存下来，放到其他位置去分析，建议使用 Linux 环境或者 Windows WSL。

1. 环境准备

• 安装好dotnet，最好与分析的应用程序一致
• 安装 lldb，3.9 到 9 版本
• dotnet tool install –g dotnet-sos && dotnet-sos install 实现 sos 插件的自动加载
• dotnet tool install -g dotnet-symbol 下载分析 coredump 所需的模块和符号
• 应用的pdb文件

2. 将应用的pdb文件放到和线上运行环境一样的目录下。若线上部署目录是/app，则也需要在当前机器的/app下放置相同的文件。若缺少此步骤，在使用clrstack 时，将看到不代码行号。如下图所示。

3. lldb-3.9 dotnet -c <coredump path> 加载 dump 文件。即可开始分析。

4. 如果在上一步执行 sos 失败，则需要先在 coredump 所在的文件夹执行 dotnet-symbol --host-only --debugging <dump file path> 下载需要的文件。

如何将 dotnet-dump 创建的 coredump 文件转移到其他位置分析

1. 环境准备

• 安装好dotnet，最好与分析的应用程序一致
• dotnet tool install –g dotnet-dump
• dotnet tool install -g dotnet-symbol 下载分析 coredump 所需的模块和符号
• 应用的pdb文件

2. 将应用的pdb文件放到和线上运行环境一样的目录下。

3. dotnet-dump analyze <dump_path> 加载 dump 文件。即可开始分析。

4. 如果在上一步执行 sos 失败，则需要先在 coredump 所在的文件夹执行 dotnet-symbol --host-only --debugging <dump file path> 下载需要的文件。