使用 SOS 對 Linux 中執行的 .NET Core 進行問題診斷
- 說明
- 準備一個方便的學習環境
- 工具介紹
- 案例分析
- .NET Core 3.x 的不同點
- 如何將 createdump 建立的 coredump 檔案轉移到其他位置分析
- 如何將 dotnet-dump 建立的 coredump 檔案轉移到其他位置分析
說明
- 本文主要描述 Linux 環境下 .NET Core 程式的問題分析方案,也會提及如何將 Linux 系統中儲存好的
core dump
- 將依次講解如何在 .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 = 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
基於EventCounterAPI 釋出的 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>
下載需要的檔案。