一：背景 1. 講故事 前些天有位朋友找到我，說他們的程式記憶體會偶發性暴漲，自己分析了下是非托管記憶體問題，讓我幫忙看下怎麼回事？哈哈，看到這個dump我還是非常有興趣的，居然還有這種游戲幣自助機類型的程式，下次去大玩家看看他們出幣的機器後端是不是C#寫的？由於dump是linux上的程式，剛好win ...
一：背景
1. 講故事
前些天有位朋友找到我，說他們的程式記憶體會偶發性暴漲，自己分析了下是非托管記憶體問題，讓我幫忙看下怎麼回事？哈哈，看到這個dump我還是非常有興趣的，居然還有這種游戲幣自助機類型的程式，下次去大玩家看看他們出幣的機器後端是不是C#寫的？由於dump是linux上的程式，剛好windbg可以全平臺分析，太爽了，直接用windbg開乾吧。
二：WinDbg 分析
1. 到底是哪裡的泄漏
在 windows 平臺上相信有很多朋友都知道用 !address -summary 命令看，但這是專屬於windows平臺的命令，在分析linux上的dump不好使，參考如下輸出：
0:000> !address -summary
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
<unknown> 1685 7ffc`d6725c00 ( 127.988 TB) 100.00% 100.00%
Image 7102 0`0b524400 ( 181.142 MB) 0.00% 0.00%
--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
2248 7ffc`02549000 ( 127.984 TB) 100.00%
MEM_PRIVATE 6539 0`df701000 ( 3.491 GB) 0.00% 0.00%
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
2248 7ffc`02549000 ( 127.984 TB) 100.00% 100.00%
MEM_COMMIT 6539 0`df701000 ( 3.491 GB) 0.00% 0.00%
--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 2099 0`dd75e000 ( 3.460 GB) 0.00% 0.00%
PAGE_EXECUTE_WRITECOPY 33 0`00d4c000 ( 13.297 MB) 0.00% 0.00%
PAGE_READONLY 2736 0`00b01000 ( 11.004 MB) 0.00% 0.00%
PAGE_EXECUTE_READ 1671 0`00756000 ( 7.336 MB) 0.00% 0.00%
--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
<unknown> 0`00000000 55cb`2dc3b000 ( 85.794 TB)
Image 7f71`9dbdd000 0`01b16000 ( 27.086 MB)
卦中的記憶體段分類用處不大，也沒有多大的參考價值，那怎麼辦呢？其實 coreclr 團隊也考慮到了這個情況，它提供了一個 maddress 命令來實現跨平臺的 !address，更改後輸出如下：
0:000> !sos maddress
Enumerating and tagging the entire address space and caching the result...
Subsequent runs of this command should be faster.
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Memory Kind | StartAddr | EndAddr-1 | Size | Type | State | Protect | Image |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Stack | 7f6e356ec000 | 7f6e35eec000 | 8.00mb | MEM_PRIVATE | MEM_COMMIT | PAGE_READWRITE | |
| Stack | 7f6e35eed000 | 7f6e366ed000 | 8.00mb | MEM_PRIVATE | MEM_COMMIT | PAGE_READWRITE | |
| Stack | 7f6e366ee000 | 7f6e36eee000 | 8.00mb | MEM_PRIVATE | MEM_COMMIT | PAGE_READWRITE | |
| Stack | 7f6e36eef000 | 7f6e376ef000 | 8.00mb | MEM_PRIVATE | MEM_COMMIT | PAGE_READWRITE | |
...
+-------------------------------------------------------------------------+
| Memory Type | Count | Size | Size (bytes) |
+-------------------------------------------------------------------------+
| Stack | 423 | 3.29gb | 3,528,859,648 |
| Image | 7,102 | 181.14mb | 189,940,736 |
| PAGE_READWRITE | 206 | 89.18mb | 93,511,680 |
| GCHeap | 3 | 37.75mb | 39,587,840 |
| HighFrequencyHeap | 395 | 24.66mb | 25,858,048 |
| LowFrequencyHeap | 316 | 22.20mb | 23,277,568 |
| LoaderCodeHeap | 13 | 17.00mb | 17,825,792 |
| ResolveHeap | 2 | 732.00kb | 749,568 |
| HostCodeHeap | 8 | 668.00kb | 684,032 |
| DispatchHeap | 1 | 196.00kb | 200,704 |
| PAGE_EXECUTE_WRITECOPY | 6 | 184.00kb | 188,416 |
| CacheEntryHeap | 3 | 164.00kb | 167,936 |
| IndirectionCellHeap | 3 | 152.00kb | 155,648 |
| LookupHeap | 3 | 144.00kb | 147,456 |
| StubHeap | 2 | 76.00kb | 77,824 |
| PAGE_EXECUTE_READ | 1 | 4.00kb | 4,096 |
+-------------------------------------------------------------------------+
| [TOTAL] | 8,487 | 3.65gb | 3,921,236,992 |
+-------------------------------------------------------------------------+
從卦中可以看到當前程式總計 3.65G 記憶體占用，基本上都被線程棧給吃掉了，更讓人意想不到的是這個線程棧居然占用 8M 的記憶體空間，這個著實有點大了，而且 linux 不像 windows 有一個 reserved 的概念，這裡的 8M 是實實在在的預占，可以觀察這 8M 的記憶體地址即可，都是初始化的 0, 這就說不過去了。
0:000> dp 7f6e356ec000 7f6e35eec000
00007f6e`356ec000 00000000`00000000 00000000`00000000
...
00007f6e`35eebfc0 00000000`00000000 00000000`00000000
00007f6e`35eebfd0 00000000`00000000 00000000`00000000
00007f6e`35eebfe0 00000000`00000000 00000000`00000000
00007f6e`35eebff0 00000000`00000000 00000000`00000000
2. 如何修改棧空間大小
一般來說不同的操作系統發行版有不同的預設棧空間配置，可以先到記憶體搜一下當前是哪一個發行版，做法就是搜索操作系統名稱主要關鍵字。
0:000> s-a 0 L?0xffffffffffffffff "centos"
...
000055cb`2ecf08c8 63 65 6e 74 6f 73 2e 37-2d 78 36 34 00 00 00 00 centos.7-x64....
...
從卦中可以看到當前操作系統是 centos7-x64，在 windows 平臺上修改棧空間大小可以修改 PE 頭，在 linux 上有兩種做法。
- 修改 ulimit -s 參數
root@ubuntu:/data# ulimit -s
8192
root@ubuntu:/data# ulimit -s 2048
root@ubuntu:/data# ulimit -s
2048
- 修改 DOTNET_DefaultStackSize 環境變數
DOTNET_DefaultStackSize=180000
更多可以參考文章： https://www.alexander-koepke.de/post/2023-10-18-til-dotnet-stack-size/
上面是解決問題的第一個方向，接下來我們說另一個方向，為什麼會產生總計 423 個線程呢？
3. 為什麼會有那麼多線程
要找到這個答案，需要去看每一個線程此時都在幹嘛，這個可以使用 windbg 專屬命令。
0:000> ~*e !clrstack
...
OS Thread Id: 0x4e (24)
Child SP IP Call Site
00007F70B20FC4B0 00007f71a4131ad8 [InlinedCallFrame: 00007f70b20fc4b0] /app/Confluent.Kafka.dll!Unknown
00007F70B20FC4B0 00007f7130299970 [InlinedCallFrame: 00007f70b20fc4b0] /app/Confluent.Kafka.dll!Unknown
00007F70B20FC4A0 00007f7130299970 ILStubClass.IL_STUB_PInvoke(IntPtr, IntPtr)
00007F70B20FC530 00007f7130309fab /app/Confluent.Kafka.dll!Unknown
00007F70B20FC880 00007f7131c5a75d /app/Confluent.Kafka.dll!Unknown
00007F70B20FC8A0 00007f7130303ebe /app/DotNetCore.CAP.Kafka.dll!Unknown
00007F70B20FC980 00007f71302f4854 /app/DotNetCore.CAP.dll!Unknown
00007F70B20FCA50 00007f7129b187f4 System.Threading.Tasks.Task.InnerInvoke() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs @ 2387]
00007F70B20FCA70 00007f7129b1d316 System.Threading.Tasks.Task+c.<.cctor>b__272_0(System.Object) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs @ 2375]
00007F70B20FCA80 00007f7129b03d6b System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs @ 183]
00007F70B20FCAD0 00007f7129b18524 System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef, System.Threading.Thread) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs @ 2333]
00007F70B20FCB50 00007f7129b18418 System.Threading.Tasks.Task.ExecuteEntryUnsafe(System.Threading.Thread) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs @ 2271]
00007F70B20FCB70 00007f7129b21a67 System.Threading.Tasks.ThreadPoolTaskScheduler+c.<.cctor>b__10_0(System.Object) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/ThreadPoolTaskScheduler.cs @ 35]
00007F70B20FCB80 00007f7129af88c2 System.Threading.Thread.StartCallback() [/_/src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs @ 105]
00007F70B20FCCF0 00007f71a37ab9c7 [DebuggerU2MCatchHandlerFrame: 00007f70b20fccf0]
...
從卦中數據看有很多的 Unknown，說明dump取得不好，可能不是用正規的 dotnet-dump 或者 procdump，但不管怎麼說，還是可以看到大量的和 Kafka 有關的鏈接庫，並且從 InnerInvoke 這個執行 m_action 來看，應該是有大量線程卡在 Kafka 中的某個函數上。
有了這些知識，最後給到朋友的建議如下：
- 修改 DOTNET_DefaultStackSize 參數
可以仿照 windows 上的 .netcore 預設 1.5M 的棧空間設置，因為8M真的太大了，扛不住，也和 Linux 的低記憶體使用不符。
- 觀察 Kafka 的相關邏輯
畢竟有大量線程在 Kafka 的等待上，個人覺得可能是訂閱線程太多，或者什麼業務執行時間長導致的線程饑餓，儘量把線程壓下去。
三：總結
Linux 上的 .NET 調試生態在日漸豐富，這是一件讓人很興奮的事情，最後再給 WinDbg 點個贊，它不僅可以全平臺dump分析，還可以實時調試 Linux 進程，現如今的WinDbg真的是神一般的存在。
