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

说明
准备一个方便的学习环境
- 2.x 配置内容
- 3.x 配置内容
工具介绍
- lldb sos plugin
  - 1. attach 到进程上进行调试
  - 2. 分析core dump文件
- SOS
案例分析
.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 安装到，后面也会讲到具体的操作。
使用 createdump 必须开启 SYS_PTRACE，3.x 和 5.x 中使用 dotnet-dump 不需要开启 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://dzone.com/articles/pinpointing-static-gc-root-sos

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下放置相同的文件，或者通过 setsymbolserver -directory 设置 pdb 目录。若缺少此步骤，在使用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> 下载需要的文件。

posted @ 2021-01-03 12:57 黑洞视界阅读(3833) 评论(5) 编辑收藏举报

刷新页面返回顶部

黑洞视界

使用 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 文件转移到其他位置分析

公告