記一次 .NET 某電力系統 記憶體暴漲分析

来源:https://www.cnblogs.com/huangxincheng/archive/2023/09/18/17710972.html
-Advertisement-
Play Games

一:背景 1. 講故事 前些天有位朋友找到我,說他生產上的程式有記憶體暴漲情況,讓我幫忙看下怎麼回事,最簡單粗暴的方法就是讓朋友在記憶體暴漲的時候抓一個dump下來,看一看大概就知道咋回事了。 二:Windbg 分析 1. 到底是誰吃了記憶體 這個問題說的再多也不為過,一定要看清楚這個程式是如何個性化發展 ...


一:背景

1. 講故事

前些天有位朋友找到我,說他生產上的程式有記憶體暴漲情況,讓我幫忙看下怎麼回事,最簡單粗暴的方法就是讓朋友在記憶體暴漲的時候抓一個dump下來,看一看大概就知道咋回事了。

二:Windbg 分析

1. 到底是誰吃了記憶體

這個問題說的再多也不為過,一定要看清楚這個程式是如何個性化發展的,可以使用 !address -summary 命令。


0:000> !address -summary

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                    255     7dfb`064e1000 ( 125.981 TB)           98.42%
<unknown>                               529      204`d53ac000 (   2.019 TB)  99.97%    1.58%
Heap                                    889        0`170f0000 ( 368.938 MB)   0.02%    0.00%
Image                                  1214        0`07a9a000 ( 122.602 MB)   0.01%    0.00%
Stack                                   192        0`05980000 (  89.500 MB)   0.00%    0.00%
Other                                    10        0`001d8000 (   1.844 MB)   0.00%    0.00%
TEB                                      64        0`00080000 ( 512.000 kB)   0.00%    0.00%
PEB                                       1        0`00001000 (   4.000 kB)   0.00%    0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                                255     7dfb`064e1000 ( 125.981 TB)           98.42%
MEM_RESERVE                             709      204`43eab000 (   2.017 TB)  99.86%    1.58%
MEM_COMMIT                             2190        0`b5c64000 (   2.840 GB)   0.14%    0.00%

從卦象看進程記憶體也才 2.84G,嚴格來說也不算多,可能朋友抓的有點心急,從上面的 unknown 指標看大概率是托管堆的暴漲,繼續使用 !eeheap -gc 觀察下托管堆。


0:000> !eeheap -gc

========================================
Number of GC Heaps: 4
----------------------------------------
Heap 0 (000001d0adf50a20)
generation 0 starts at 1d0b3fad350
generation 1 starts at 1d0b3f9be88
generation 2 starts at 1d0ae5d1000
ephemeral segment allocation context: none
Small object heap
         segment            begin        allocated        committed allocated size          committed size         
    01d0ae5d0000     01d0ae5d1000     01d0b4046258     01d0b48ac000 0x5a75258 (94851672)    0x62dc000 (103661568)  
Large object heap starts at 1d4ae5d1000
         segment            begin        allocated        committed allocated size          committed size         
    01d4ae5d0000     01d4ae5d1000     01d4b6d0c4e8     01d4b6d2d000 0x873b4e8 (141800680)   0x875d000 (141938688)  
Pinned object heap starts at 1d4ee5d1000
         segment            begin        allocated        committed allocated size          committed size         
    01d4ee5d0000     01d4ee5d1000     01d4ee5e4f08     01d4ee5f2000 0x13f08 (81672)         0x22000 (139264)       
------------------------------
...
Heap 3 (000001d0ae4fd000)
generation 0 starts at 1d3b26929e0
generation 1 starts at 1d3b2687ad8
generation 2 starts at 1d3ae5d1000
ephemeral segment allocation context: none
Small object heap
         segment            begin        allocated        committed allocated size          committed size         
    01d3ae5d0000     01d3ae5d1000     01d4179a5980     01d418021000 0x693d4980 (1765624192) 0x69a51000 (1772425216)
Large object heap starts at 1d4de5d1000
         segment            begin        allocated        committed allocated size          committed size         
    01d4de5d0000     01d4de5d1000     01d4df8836d8     01d4df884000 0x12b26d8 (19605208)    0x12b4000 (19611648)   
Pinned object heap starts at 1d51e5d1000
         segment            begin        allocated        committed allocated size          committed size         
    01d51e5d0000     01d51e5d1000     01d51e5dd7e0     01d51e5e2000 0xc7e0 (51168)          0x12000 (73728)        
------------------------------
GC Allocated Heap Size:    Size: 0x8a6b9060 (2322305120) bytes.
GC Committed Heap Size:    Size: 0x8c6b1000 (2355826688) bytes.

從GC堆看果然是托管層的問題,繼續使用 !dumpheap -stat 觀察下托管堆的現狀,看看哪一位是罪魁禍首。


0:000> !dumpheap -stat
Statistics:
          MT     Count     TotalSize Class Name
...
7fff32e81db8        43    68,801,032 SmartMeter.Mem.TerminalInfo[]
7fff329f7470   200,000   110,400,000 SmartMeter.Model.MeterInfo_Model
7fff3227d708 2,285,392   116,193,998 System.String
01d0ae46b350       543 1,857,281,320 Free
Total 3,947,969 objects, 2,314,533,332 bytes

Fragmented blocks larger than 0.5 MB:
         Address           Size      Followed By
    01d0ae935870        723,384     01d0ae9e6228 System.SByte[]
    01d1b41d3cd0     23,081,616     01d1b57d6f60 System.Byte[]
    01d3b274eb40  1,696,943,656     01d4179a3968 System.Byte[]

這卦不看不知道,一看嚇一跳,這2.3G的記憶體,居然被一個 1.69G 的Free給侵吞了,不信的話可以用 !do 驗證下。


0:000> !do 01d3b274eb40
Free Object
Size:        1696943656(0x65254e28) bytes

2. 為什麼會有這麼大的Free

這是一個值得思考的問題,也決定著我們下一步分析的方向,接下來就是看下這個 free 的落腳點以及周圍對象的分佈情況,可以使用 !gcwhere 觀察。


0:000> !gcwhere 01d3b274eb40
Address          Heap   Segment          Generation Allocated               Committed               Reserved               
01d3b274eb40     3      01d3ae5d0000     0          1d3ae5d1000-1d4179a5980 1d3ae5d0000-1d418021000 1d418021000-1d4ae5d0000

0:000> !dumpheap -segment 1d3ae5d0000
    ...
    01d3b274e948     7fff32468658             96 
    01d3b274e9a8     7fff3227d708             28 
    01d3b274e9c8     7fff3227d708             28 
    01d3b274e9e8     7fff32d0c8d8             80 
    01d3b274ea38     7fff3227d708             96 
    01d3b274ea98     7fff32d0aa38             40 
    01d3b274eac0     01d0ae46b350            128 Free
    01d3b274eb40     01d0ae46b350  1,696,943,656 Free
    01d4179a3968     7fff323e1638          8,216 

從卦象看挺遺憾的,如果 Free 落在segment的最後一個位置,那麼 segment 就會 uncommitted 進而記憶體就下去了,可偏偏最後一個位置是 8216byte 的對象占據著,阻止了記憶體的回收,有經驗的朋友可能知道,這個對象非富即貴,大概率是被 pinned 了,可以用 !gcroot 觀察下。


0:000> !gcroot 01d4179a3968
HandleTable:
    000001d0ae3927f8 (async pinned handle)
          -> 01d3b26706f0     System.Threading.OverlappedData 
          -> 01d4179a3968     System.Byte[] 

Found 1 unique roots.

0:000> !dumpobj /d 1d4179a3968
Name:        System.Byte[]
MethodTable: 00007fff323e1638
EEClass:     00007fff323e15b8
Tracked Type: false
Size:        8216(0x2018) bytes
Array:       Rank 1, Number of elements 8192, Type Byte (Print Array)
Content:     ............L.o.g.\.2.0.2.3.0...
Fields:
None

從上面的 async pinned handle 來看是一個文件監控的回調函數,到這裡就可以從表象解釋:是這個 8216 的對象導致的記憶體無法回收。

3. 真的要 8216 來擔責嗎

如果你真的要讓 8216 來擔責,那真的只看到了表象,記憶體的突然暴漲回不去只是恰好遇到了 8216 的阻止,但它不是本質原因,真正要考慮的是為什麼GC回收後會產生這麼大一個單獨 Free,其實隱喻了當前程式出現過短時的 大對象分配,對,就是這個詞。

接下來的問題是如何找到這個 大對象分配 呢? 最好的方法就是用 perfview 的 .NET SampAlloc 去洞察,如果非要用 WinDbg 的話那就只能看看 Free 生前是什麼,或許能尋找到答案,可以藉助 .writemem 命令觀察。


0:000> !do 01d3b274eb40
Free Object
Size:        1696943656(0x65254e28) bytes

0:000> .writemem D:\testdump\1.txt 01d3b274eb40 L?0x65254e28
Writing 65254e28 bytes................

從卦中數據看有大量的計費信息,看樣子又是從資料庫中短時的撈取了大批量數據在托管堆上折騰導致的,知道了本質原因,解決辦法就比較簡單了,通常有兩種做法。

  • 修改 GC 模式,改成 Workstation。

  • 大批量數據 改成 小步快跑

三:總結

這起記憶體暴漲事故,表象上是 8216 的阻擋導致了記憶體無法被uncommitted所致,本質上還是歸於托管堆的 記憶體黑洞 現象。


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

-Advertisement-
Play Games
更多相關文章
  • gRPC 是開發中常用的開源高性能遠程過程調用(RPC)框架,tonic 是基於 HTTP/2 的 gRPC 實現,專註於高性能、互操作性和靈活性。該庫的創建是為了對 async/await 提供一流的支持,並充當用 Rust 編寫的生產系統的核心構建塊。今天我們聊聊通過使用tonic 調用grpc... ...
  • 來源:虛無境的博客 地址:www.cnblogs.com/xuwujing/p/11953697.html 在介紹Nginx的負載均衡實現之前,先簡單的說下負載均衡的分類,主要分為硬體負載均衡和軟體負載均衡,硬體負載均衡是使用專門的軟體和硬體相結合的設備,設備商會提供完整成熟的解決方案,比如F5,在 ...
  • CRC校驗技術是用於檢測數據傳輸或存儲過程中是否出現了錯誤的一種方法,校驗演算法可以通過計算應用與數據的迴圈冗餘校驗(CRC)檢驗值來檢測任何數據損壞。通過運用本校驗技術我們可以實現對特定記憶體區域以及磁碟文件進行完整性檢測,並以此來判定特定程式記憶體是否發生了變化,如果發生變化則拒絕執行,通過此種方法來... ...
  • 近些年來,隨著WPF在生產,製造,工業控制等領域應用越來越廣發,很多企業對WPF開發的需求也逐漸增多,使得很多人看到潛在機會,不斷從Web,WinForm開發轉向了WPF開發,但是WPF開發也有很多新的概念及設計思想,如:數據驅動,數據綁定,依賴屬性,命令,控制項模板,數據模板,MVVM等,與傳統Wi... ...
  • 在我們展示一些參考信息的時候,有所會用樹形列表來展示結構信息,如對於有父子關係的多層級部門機構,以及一些常用如字典大類節點,也都可以利用樹形列表的方式進行展示,本篇隨筆介紹基於WPF的方式,使用TreeView來洗實現結構信息的展示,以及對它的菜單進行的設置、過濾查詢等功能的實現邏輯。 ...
  • 有關mmd播放器,網上也有許多非常漂亮的實現,如 pmxeditor、saba、blender_mmd_tools等等。。 首先我想先介紹下我參考實現的倉庫: sselecirPyM/Coocoo3D: Experimental MMD renderer using DX12 and DXR. (g ...
  • 在我們設計軟體的很多地方,都看到需要對錶格數據進行導入和導出的操作,主要是方便客戶進行快速的數據處理和分享的功能,本篇隨筆介紹基於WPF實現DataGrid數據的導入和導出操作。 ...
  • 摘要:本智能化住宅防盜報警系統通過PLC以及組態監控實現了多種功能。系統可以自動控制和手動控制,在家人離開後啟動,在到達家後停止。當家裡沒有人時,系統會模擬有人居住的情況,通過設置燈光變換和排氣扇間斷工作來製造有人的情況。晚上通過設置燈光的變化來模擬生活的場景,白天的時候關閉燈光,晚上的時候打開卧室 ...
一周排行
    -Advertisement-
    Play Games
  • 前言 推薦一款基於.NET 8、WPF、Prism.DryIoc、MVVM設計模式、Blazor以及MySQL資料庫構建的企業級工作流系統的WPF客戶端框架-AIStudio.Wpf.AClient 6.0。 項目介紹 框架採用了 Prism 框架來實現 MVVM 模式,不僅簡化了 MVVM 的典型 ...
  • 先看一下效果吧: 我們直接通過改造一下原版的TreeView來實現上面這個效果 我們先創建一個普通的TreeView 代碼很簡單: <TreeView> <TreeViewItem Header="人事部"/> <TreeViewItem Header="技術部"> <TreeViewItem He ...
  • 1. 生成式 AI 簡介 https://imp.i384100.net/LXYmq3 2. Python 語言 https://imp.i384100.net/5gmXXo 3. 統計和 R https://youtu.be/ANMuuq502rE?si=hw9GT6JVzMhRvBbF 4. 數 ...
  • 本文為大家介紹下.NET解壓/壓縮zip文件。雖然解壓縮不是啥核心技術,但壓縮性能以及進度處理還是需要關註下,針對使用較多的zip開源組件驗證,給大家提供個技術選型參考 之前在《.NET WebSocket高併發通信阻塞問題 - 唐宋元明清2188 - 博客園 (cnblogs.com)》講過,團隊 ...
  • 之前寫過兩篇關於Roslyn源生成器生成源代碼的用例,今天使用Roslyn的代碼修複器CodeFixProvider實現一個cs文件頭部註釋的功能, 代碼修複器會同時涉及到CodeFixProvider和DiagnosticAnalyzer, 實現FileHeaderAnalyzer 首先我們知道修 ...
  • 在軟體行業,經常會聽到一句話“文不如表,表不如圖”說明瞭圖形在軟體應用中的重要性。同樣在WPF開發中,為了程式美觀或者業務需要,經常會用到各種個樣的圖形。今天以一些簡單的小例子,簡述WPF開發中幾何圖形(Geometry)相關內容,僅供學習分享使用,如有不足之處,還請指正。 ...
  • 在 C# 中使用 RabbitMQ 通過簡訊發送重置後的密碼到用戶的手機號上,你可以按照以下步驟進行 1.安裝 RabbitMQ 客戶端庫 首先,確保你已經安裝了 RabbitMQ 客戶端庫。你可以通過 NuGet 包管理器來安裝: dotnet add package RabbitMQ.Clien ...
  • 1.下載 Protocol Buffers 編譯器(protoc) 前往 Protocol Buffers GitHub Releases 頁面。在 "Assets" 下找到適合您系統的壓縮文件,通常為 protoc-{version}-win32.zip 或 protoc-{version}-wi ...
  • 簡介 在現代微服務架構中,服務發現(Service Discovery)是一項關鍵功能。它允許微服務動態地找到彼此,而無需依賴硬編碼的地址。以前如果你搜 .NET Service Discovery,大概率會搜到一大堆 Eureka,Consul 等的文章。現在微軟為我們帶來了一個官方的包:Micr ...
  • ZY樹洞 前言 ZY樹洞是一個基於.NET Core開發的簡單的評論系統,主要用於大家分享自己心中的感悟、經驗、心得、想法等。 好了,不賣關子了,這個項目其實是上班無聊的時候寫的,為什麼要寫這個項目呢?因為我單純的想吐槽一下工作中的不滿而已。 項目介紹 項目很簡單,主要功能就是提供一個簡單的評論系統 ...