記一次 .NET 某電子廠OA系統 非托管記憶體泄露分析

来源:https://www.cnblogs.com/huangxincheng/archive/2022/12/02/16945067.html
-Advertisement-
Play Games

一：背景 1.講故事 這周有個朋友找到我，說他的程式出現了記憶體緩慢增長，沒有回頭的趨勢，讓我幫忙看下到底怎麼回事，據朋友說這個問題已經困擾他快一周了，還是沒能找到最終的問題，看樣子這個問題比較刁鑽，不管怎麼說，先祭出 WinDbg。 二：WinDbg 分析 1. 托管還是非托管泄露 一直關註這個系列 ...


一：背景

1.講故事

這周有個朋友找到我，說他的程式出現了記憶體緩慢增長，沒有回頭的趨勢，讓我幫忙看下到底怎麼回事，據朋友說這個問題已經困擾他快一周了，還是沒能找到最終的問題，看樣子這個問題比較刁鑽，不管怎麼說，先祭出 WinDbg。

二：WinDbg 分析

1. 托管還是非托管泄露

一直關註這個系列的朋友都知道，托管和非托管的排查是兩個體系，分析方式完全不一樣，所以要鑒定是哪一塊的記憶體問題，首先要用 !address -summary 觀察進程的 虛擬記憶體 佈局。


0:000> !address -summary

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                    710     7d93`20465000 ( 125.575 TB)           98.11%
<unknown>                              7547      240`9bea8000 (   2.252 TB)  92.87%    1.76%
Stack                                 33363       2c`1fae0000 ( 176.495 GB)   7.11%    0.13%
Heap                                   1179        0`126d3000 ( 294.824 MB)   0.01%    0.00%
Image                                  2988        0`0c274000 ( 194.453 MB)   0.01%    0.00%
TEB                                   11121        0`056e2000 (  86.883 MB)   0.00%    0.00%
Other                                    11        0`001d9000 (   1.848 MB)   0.00%    0.00%
PEB                                       1        0`00001000 (   4.000 kB)   0.00%    0.00%

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_MAPPED                             7302      200`071b1000 (   2.000 TB)  82.47%    1.56%
MEM_PRIVATE                           45920       6c`cc766000 ( 435.195 GB)  17.52%    0.33%
MEM_IMAGE                              2988        0`0c274000 ( 194.453 MB)   0.01%    0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                                710     7d93`20465000 ( 125.575 TB)           98.11%
MEM_RESERVE                           12136      26c`84ccf000 (   2.424 TB)  99.94%    1.89%
MEM_COMMIT                            44074        0`5aebc000 (   1.421 GB)   0.06%    0.00%

從卦中看，當前進程的提交記憶體是 MEM_COMMIT= 1.4G， NT堆的記憶體占用是 Heap=294M，乍一看應該是托管記憶體泄露，接下來用 !eeheap -gc 觀察托管堆。


0:000> !eeheap -gc
Number of GC Heaps: 12
------------------------------
Heap 0 (0000028577D73020)
generation 0 starts at 0x00000285B7000020
generation 1 starts at 0x00000285B6C00020
generation 2 starts at 0x0000028590800020
ephemeral segment allocation context: none
...
------------------------------
GC Allocated Heap Size:    Size: 0x9598958 (156862808) bytes.
GC Committed Heap Size:    Size: 0xea1c7e0 (245483488) bytes.

從卦中看很奇怪，托管堆也就 GC Committed Heap Size= 245M 的記憶體占用，說明問題不在托管堆上。

2. 到底是哪裡的泄露

這就是本篇文章的亮點之處，畢竟沒有按照以前的套路出牌，接下來問題在哪裡呢？ 還是得回頭看下 虛擬記憶體佈局，終於你會發現 Stack 處很奇怪，記憶體占用高達 TotalSize =176G， 記憶體段高達 RgnCount=3.3w，截圖如下：

這兩個蛛絲馬跡已經告訴我們當前開啟了非常多的線程，可以用 !address: -f:Stack 觀察線程數和線程棧信息。


0:000> !address -f:Stack

        BaseAddress      EndAddress+1        RegionSize     Type       State                 Protect             Usage
--------------------------------------------------------------------------------------------------------------------------
      c0`80000000       c0`8104b000        0`0104b000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~139; 323a8.320a4]
      c0`8104b000       c0`8104e000        0`00003000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~139; 323a8.320a4]
      c0`8104e000       c0`81050000        0`00002000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~139; 323a8.320a4]
      c0`81050000       c0`8209b000        0`0104b000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~140; 323a8.316b8]
      c0`8209b000       c0`8209e000        0`00003000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~140; 323a8.316b8]
      c0`8209e000       c0`820a0000        0`00002000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~140; 323a8.316b8]
      ...
      ed`460d0000       ed`4711b000        0`0104b000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~11119; 323a8.8b20]
      ed`4711b000       ed`4711e000        0`00003000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~11119; 323a8.8b20]
      ed`4711e000       ed`47120000        0`00002000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~11119; 323a8.8b20]
      ed`47120000       ed`4816b000        0`0104b000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~11120; 323a8.9828]
      ed`4816b000       ed`4816e000        0`00003000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~11120; 323a8.9828]
      ed`4816e000       ed`48170000        0`00002000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~11120; 323a8.9828]

從卦中看，當前線程高達 1.1w 個，有點嚇人，終於算是找到源頭了，

3. 為什麼會有 1w+ 的線程

接下來就需要鑒定下這些線程是托管線程還是非托管線程，可以用 !t 觀察。


0:000> !t
ThreadCount:      11104
UnstartedThread:  0
BackgroundThread: 11099
PendingThread:    0
DeadThread:       4
Hosted Runtime:   no
                                                                                                            Lock  
 DBG   ID     OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception
  20    1    32588 0000028577D0DB30  202a020 Preemptive  0000000000000000:0000000000000000 0000028577529fc0 -00001 MTA 
  35    2    3262c 0000028577F3D000    2b220 Preemptive  00000285C0002660:00000285C0004008 0000028577529fc0 -00001 MTA (Finalizer) 
  36    4    326b4 0000028577F941B0  102b220 Preemptive  0000000000000000:0000000000000000 0000028577529fc0 -00001 MTA (Threadpool Worker) 
  37    5    31848 000002857811A420  202b220 Preemptive  0000000000000000:0000000000000000 0000028577529fc0 -00001 MTA 
  ...
11116 11100     966c 000002C620A45300  202b220 Preemptive  00000285C86CB910:00000285C86CD868 0000028577529fc0 -00001 MTA 
11117 11101     95b4 000002C61B928970  202b220 Preemptive  00000285996DF978:00000285996E18D0 0000028577529fc0 -00001 MTA 
11118 11102     9630 000002C61B928FC0  202b220 Preemptive  00000285996E1978:00000285996E38D0 0000028577529fc0 -00001 MTA 
11119 11103     8b20 000002C620A465F0  202b220 Preemptive  00000285B46B15C0:00000285B46B3518 0000028577529fc0 -00001 MTA 
11120 11104     9828 000002C61E014CB0  202b220 Preemptive  00000285C86CD910:00000285C86CF868 0000028577529fc0 -00001 MTA

從卦中看： DBG 和 ID 的編號相差無幾，說明是大多是托管線程，從後面的 MTA 來看，這是一個 new Thread 出來的線程，接下來試探看下它有沒有 Name，我們拿 ThreadOBJ=000002C61E014CB0 來看吧。


0:000> dt coreclr!Thread 000002C61E014CB0
   ...
   +0x1c0 m_ExposedObject  : 0x00000285`7821d160 OBJECTHANDLE__
   ...

0:000> !do poi(0x00000285`7821d160)
Name:        System.Threading.Thread
MethodTable: 00007ffa63844320
EEClass:     00007ffa6379af48
Tracked Type: false
Size:        72(0x48) bytes
File:        D:\root\NewWF\System.Private.CoreLib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffa63a0d608  4000b0d        8 ....ExecutionContext  0 instance 00000285c0acf930 _executionContext
00007ffa64cbaa78  4000b0e       10 ...ronizationContext  0 instance 0000000000000000 _synchronizationContext
00007ffa637afd00  4000b0f       18        System.String  0 instance 0000028590888a78 _name

0:000> !DumpObj /d 0000028590888a78
Name:        System.String
MethodTable: 00007ffa637afd00
EEClass:     00007ffa6379a6e0
Tracked Type: false
Size:        98(0x62) bytes
File:        D:\root\NewWF\System.Private.CoreLib.dll
String:      Console logger queue processing thread

經過抽檢，發現線程名都是 Console logger queue processing thread，看樣子和日誌有關係，接下來使用 ~*e !clrstack 查看當前所有線程，發現線程都卡在 ConsoleLoggerProcessor.TryDequeue 上，截圖如下：

看樣子和微軟的控制台日誌組件有關係，下一步就要觀察源碼。

4. 從源碼中尋找答案

導出源碼後，利用 ILSpy 的代碼回溯功能，發現是 ConsoleLoggerProcessor 類的構造函數 new 出來的線程，截圖如下：

結合海量的重覆線程棧，大概可以猜測到是代碼將 Singleton 的模式改成了 Transient，導致不斷的 new，不斷的產生新的 Thread 去處理隊列。

接下來我也懶得細究代碼了，讓朋友重點看一下 Microsoft.Extensions.Logging.Console 組件，朋友也很給力，終於找到了是 AppService 類在不斷的 new 造成的，截圖如下：

三： 總結

這次事故如果朋友有專業的 APM 監控，相信很快就能發現 Thread 爆高的問題，從 dump 中用記憶體來反推線程爆高，確實有一點出乎意料。

這個 dump 的教訓是：理解 Singleton 和 Transient 的利弊，儘量遵循官方文檔的寫法吧。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 序章-準備工作
    前言 為什麼選擇自己開發一個詞典 市面上的詞典都不太彳亍，有Golden Dict和歐陸詞典這類註重詞典文件的，有有道詞典這類電子詞典，前者對於查詞更偏向於內容整合，後者則是釋義與例句。對於翻譯功能，兩者則都沒有整合，個人感覺很是麻煩，所以出於個人需要，決定自行開發。 開發的經歷 因為自己很喜歡UW ...
  • <一>智能指針基礎
    代碼1 int main(){ //裸指針,手動開闢,需要自己釋放,如果忘記了或者因為 //程式邏輯導致p沒有釋放,那麼就會導致記憶體泄漏 int *p=new int(10); if(***){ retur -1; } delete p; return 0; } 有沒有什麼辦法幫我們管理指針,確保資 ...
  • 【k哥爬蟲普法】爬取數據是否一定構成不正當競爭？
    我國目前並未出台專門針對網路爬蟲技術的法律規範，但在司法實踐中，相關判決已屢見不鮮，K 哥特設了“K哥爬蟲普法”專欄，本欄目通過對真實案例的分析，旨在提高廣大爬蟲工程師的法律意識，知曉如何合法合規利用爬蟲技術，警鐘長鳴，做一個守法、護法、有原則的技術人員。 案情介紹 谷米公司為開發和運營“酷米客”A ...
  • Android ViewPager2 + Fragment + BottomNavigationView 聯動
    Android ViewPager2 + Fragment + BottomNavigationView 聯動 本篇主要介紹一下 ViewPager2 + Fragment + BottomNavigationView , 上篇中把ViewPager2和Fragment 聯動起來了, 本篇主要把 B ...
  • 每日演算法之鏈表中環的入口結點
    JZ23 鏈表中環的入口結點 描述 給一個長度為n鏈表，若其中包含環，請找出該鏈表的環的入口結點，否則，返回null。 解析 環很大 在前面我們提到過快慢指針，判斷是否有環。如果有環，在來找環的入口。如果沒環直接返回null即可，我們假設是有環的，那麼會有兩種情況，一種是O型，一種是6型，其實原理都 ...
  • 【collection】1.java容器之HashMap&LinkedHashMap&Hashtable
    Map源碼剖析 HashMap&LinkedHashMap&Hashtable hashMap預設的閾值是0.75 HashMap put操作 put操作涉及3種結構，普通node節點，鏈表節點，紅黑樹節點，針對第三種，紅黑樹節點，我們後續單獨去學習，這裡不多做擴散 final V putVal(i ...
  • 面試官：你知道 Java 中的回調機制嗎？我竟然答不來。。
    來源：https://www.cnblogs.com/prayjourney/p/9667835.html 在一個應用系統中, 無論使用何種語言開發, 必然存在模塊之間的調用, 調用的方式分為幾種。 1.同步調用 同步調用是最基本並且最簡單的一種調用方式, 類A的方法a()調用類B的方法b(), 一 ...
  • 深入淺出Seata的AT模式
    在Seata的AT模式中，在服務執行完成後，直接進行RM提交和資源釋放，提供了對CAP理論相對平衡的解決方案，並且沒有侵入業務工程； ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類