[TOC] ## 說明 + 本文主要描述 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`](https://code.visualstudio.com/docs/remote/create-dev-container#remote-articles) 功能可以很方便的構建出純淨的 Linux 測試環境。這裡需要確保 Docker 執行正常。 如果不需要通過此方式構建環境，可以直接跳到下一節。 + 安裝 VS Code 外掛 `Remote - Containers`  + 建立一個資料夾並用 VS Code 開啟，在該資料夾下建立下列檔案結構 ``` 工作目錄 └── .devcontainer ├── devcontainer.json ├── docker-compose.yml └── Dockerfile ``` ### 2.x 配置內容 **devcontainer.json** ```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** ```yaml 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** ```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** ```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** ```yaml 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** ```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 命令。[點選跳轉官方文件](https://docs.microsoft.com/en-us/dotnet/framework/tools/sos-dll-sos-debugging-extension?redirectedfrom=MSDN)  `soshelp ` 可以看到每種命令具體的使用方式  使用 sos 完整命令名字 或者直接使用 別名  ## 案例分析 無論是採取的 attach 到程序的方式，還是分析 core dump 檔案的方式。最後都會進入一樣 lldb cli 介面。接下來伴隨實際的案例介紹一個新朋友，sos 指令。 ### CPU 佔用過高 測試程式碼 ```c# [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 中維護型別方法資訊等原資料的重要資料結構。和型別是一一對應的關係。 測試程式碼 ```c# [Route("api/[controller]")] public class TestController : ControllerBase { private static ConcurrentBag _cache = new ConcurrentBag(); [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 ` 根據 MethodTable 找到有問題的物件的地址。取其中一個物件的地址。如 00007fb5d8042c68。  3\. `gcroot ` 找到可能存在記憶體洩漏的根  如果能從上面的引用鏈上能找到能定位問題的地方，那故事也到此結束。如我們可以看到記憶體洩漏是發生在一個 `Concurrent.ConcurrentBag` 型別的容器上的。 4\. 尋找靜態欄位所在的型別（暫未解決） `pinned handle` 表示這是一個靜態欄位。那麼怎麼去定位這個靜態欄位所在的類呢。本人能力有限，僅找到了一篇 windbg 的老文章，暫時不知道 lldb 中如何操作。 [https://dlaa.me/blog/post/9471347](https://dlaa.me/blog/post/9471347) ### Monitor導致的死鎖 測試程式碼 ```c# 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 開始提供了一套[診斷工具](https://docs.microsoft.com/zh-cn/dotnet/core/diagnostics/)。 + 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。 安裝方式 ```sh 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 為預設型別。 + -o dump 儲存路徑，如果沒有指定，預設當前路徑  ``` dotnet-dump analyze ``` 進入之後，一樣可以用到之前提到的那些 sos 命令  因為沒有 lldb 的 `thread select ` 命令可以切換執行緒，需要使用 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 ` 載入 dump 檔案。即可開始分析。 4\. 如果在上一步執行 sos 失敗，則需要先在 coredump 所在的資料夾執行 `dotnet-symbol --host-only --debugging ` 下載需要的檔案。 ## 如何將 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 檔案。即可開始分析。 4\. 如果在上一步執行 sos 失敗，則需要先在 coredump 所在的資料夾執行 `dotnet-symbol --host-only --debugging ` 下載需要的