系统相关
首页 > 系统相关> > 使用 SOS 对 Linux 中运行的 .NET Core 进行问题诊断

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

作者:互联网

目录

说明

准备一个方便的学习环境

为了方便我们的学习,我们可以准备一下 Linux 的开发测试环境,借助 VS Code 的 Remote Containers 功能可以很方便的构建出纯净的 Linux 测试环境。这里需要确保 Docker 运行正常。
如果不需要通过此方式构建环境,可以直接跳到下一节。

工作目录
└── .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:

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

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

其中 ps aux -T | head -n1 是为了保留标题行
关键列说明:

可以看到,我们的应用进程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 查看选中线程的调用栈 栈帧确定线程执行的内容。

内存泄漏

使用 attach 或者 core dump 方式进行分析。createdump 也需要全量。
排查内存问题,我们需要用到 dumpheap 指令。

dumpheap [options] 

常用 options:

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 开始提供了一套诊断工具

本文只介绍和 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]
dotnet-dump analyze <dump_path>

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

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

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

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

1. 环境准备

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. 环境准备

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

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

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

标签:Core,dump,sos,SOS,线程,Linux,dotnet,NET,lldb
来源: https://www.cnblogs.com/blurhkh/p/14225222.html