使用 SOS 對 Linux 中運行的 .NET Core 進行問題診斷

時間  2021-01-03
標籤 linux docker shell json c# api bash 服務器 數據結構 app 欄目 Linux 简体版
原文   原文鏈接

目錄

說明

  • 本文主要描述 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 運行正常。
若是不須要經過此方式構建環境，能夠直接跳到下一節。linux

  • 安裝 VS Code 插件 Remote - Containers
  • 建立一個文件夾並用 VS Code 打開，在該文件夾下建立下列文件結構
工做目錄
└── .devcontainer
    ├── devcontainer.json
    ├── docker-compose.yml
    └── Dockerfile

2.x 配置內容

devcontainer.jsondocker

{
	"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.ymlshell

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"

Dockerfilejson

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.jsonc#

{
	"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.ymlapi

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"

Dockerfilebash

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 中也是自帶的。app

/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> 下載須要的文件。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程