使用 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 = https://www.cnblogs.com/blurhkh/p/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下放置相同的檔案，若缺少此步驟，在使用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> 下載需要的檔案，

轉載請註明出處，本文鏈接：https://www.uj5u.com/net/246501.html

標籤：.NET Core

上一篇：寶塔面板安裝紙殼CMS

下一篇：如何實作類似nameof的方法