管理堆大小及其中的所有對象的帳戶

我在調查與我的應用程序有關的高內存消耗問題。內存不斷上升，我想知道所有的內存消耗在哪裏。我有一個大小爲3GB的轉儲文件。管理堆大小及其中的所有對象的帳戶

這裏是！dumpheap -stat命令的輸出。整個列表很長，但我只想告訴你像byte []（195 MB），IdentifierChangedEventHandler（120 MB），字符串（119 MB）等最大的項目。這一切都沒有加在任何接近3GB的地方。

000007fe94169ff0 101326  7295472 System.Linq.Enumerable+WhereListIterator`1[[CommonServices.WindowsEvent.EventIDExpression+RangeExpressionCollection+RangeExpression, CommonServices]] 
000007fe94237f08  1  7786800 System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[OrderingServices.LocalCache, OrderingServices]][] 
000007fef1afc3a8 202112  8084480 System.Collections.Generic.List`1[[System.Guid, mscorlib]] 
000007fef1ac24c0 204144  9798912 System.Collections.ArrayList+ArrayListEnumeratorSimple 
000007fef1accc50 313792  10041344 System.Guid 
000007fef1ad14a0 314054  10049728 System.Security.SecureString 
000007fef1ac7790 131954  11403930 System.Char[] 
000007feed2f93b8  2063  11898472 System.Data.RBTree`1+Node[[System.Data.DataRow, System.Data]][] 
000007fef1a87890 316978  12679120 System.Security.SafeBSTRHandle 
000007fef1acc590 350337  14013480 System.Collections.ArrayList 
000007fe936bdcd0 202083  14549976 OrderingServices.LocalCache 
000007fe942db718 202083  16166640 System.Collections.Generic.Dictionary`2[[System.Guid, mscorlib],[System.Collections.Generic.HashSet`1[[System.Int32, mscorlib]], System.Core]] 
000007feed2f5910 248683  23873568 System.Data.DataRow 
000007fef1aca708 317533  25402640 System.Collections.Hashtable 
000007fe942dbf60 202021  32610456 System.Collections.Generic.Dictionary`2+Entry[[System.Guid, mscorlib],[System.Collections.Generic.HashSet`1[[System.Int32, mscorlib]], System.Core]][] 
000007fef1ac3838 319558  32975376 System.Collections.Hashtable+bucket[] 
000007fef1a74458 307557  35724224 System.Object[] 
000007feef6cc770 631242  38621784 System.Collections.Generic.HashSet`1+Slot[[System.Int32, mscorlib]][] 
000007feef6cb860 631242  40399488 System.Collections.Generic.HashSet`1[[System.Int32, mscorlib]] 
000007fef1ac9258 937270  48016624 System.Int32[] 
000007fef1ac6508 879690 119968068 System.String 
000007fef1aca690 176907 196509678 System.Byte[] 
00000000002ae930 139663 520724414  Free 
Total 14024120 objects 
Fragmented blocks larger than 0.5 MB: 
      Addr  Size  Followed by 
000000008e84f490 1.6MB 000000008e9f08b8 Microsoft.Win32.SafeHandles.SafeTokenHandle 
00000001878e1ca8 0.7MB 000000018798ffd8 Microsoft.Win32.SafeHandles.SafeTokenHandle 
0000000187ac1070 0.7MB 0000000187b76138 System.Threading.ReaderWriterLock 
0000000187d39d88 1.5MB 0000000187ec2788 System.Threading.ReaderWriterLock 
0000000187f7bfe0 0.9MB 000000018805ce90 System.Threading.ReaderWriterLock 
0000000188ad1b30 0.5MB 0000000188b5a190 System.Net.ListenerAsyncResult 
000000018909ef98 1.0MB 00000001891a9e90 System.Net.Sockets.Socket 
0000000189377440 0.6MB 0000000189417088 Microsoft.Win32.SafeHandles.SafeTokenHandle 
000000018a07e428 0.7MB 000000018a1382a0 System.Threading.ExecutionContext 
000000018a599610 1.2MB 000000018a6d4b50 Microsoft.Win32.SafeHandles.SafeTokenHandle 
000000018bad8b30 0.7MB 000000018bb87b00 Microsoft.Win32.SafeHandles.SafeTokenHandle 
000000018bb88778 1.1MB 000000018bcac050 System.Threading.ReaderWriterLock 
000000018bcac618 1.3MB 000000018bdee998 Microsoft.Win32.SafeHandles.SafeTokenHandle 
000000018ed68b78 1.0MB 000000018ee6c290 System.Threading.ReaderWriterLock 
000000018eec5b70 0.9MB 000000018efb37a8 System.Threading.ReaderWriterLock 
000000018f351930 0.7MB 000000018f40edb0 Microsoft.Win32.SafeHandles.SafeTokenHandle 
000000018f469d00 0.6MB 000000018f509360 System.Net.ListenerAsyncResult 
000000018f5508d8 2.8MB 000000018f824ad8 Microsoft.Win32.SafeHandles.SafeTokenHandle 
000000018f917610 2.2MB 000000018fb41790 Microsoft.Win32.SafeHandles.SafeTokenHandle 
000000028985e148 0.6MB 00000002898f72e0 System.Security.SafeBSTRHandle 
0000000289901008 0.8MB 00000002899c3138 System.Security.SafeBSTRHandle 
000000028a1e7378 0.7MB 000000028a295dd8 System.Net.ListenerAsyncResult 
000000028a56a8b8 1.3MB 000000028a6c23c8 System.Threading.ReaderWriterLock 
000000028a8c0a28 0.9MB 000000028a9b2b88 MonitoringServices.PerformanceCounter.PerformanceCounterDataPoint 
000000028b1b80c8 0.9MB 000000028b2a6a30 System.Data.SqlClient.SNIPacket 
000000028d37d7c0 0.6MB 000000028d4220f0 System.Transactions.SafeIUnknown 
000000028d5f05c8 1.6MB 000000028d789b20 System.Net.ListenerAsyncResult 
000000028d78ac08 2.4MB 000000028d9e7e58 System.Transactions.SafeIUnknown 
000000028d9ec618 0.7MB 000000028da95c88 System.Threading.ReaderWriterLock 
000000028daa5f58 1.2MB 000000028dbe2af8 System.Threading.ReaderWriterLock 
000000028dbe3b00 0.7MB 000000028dc98aa0 System.Threading.ReaderWriterLock 
000000028dc99aa8 1.6MB 000000028de30e40 System.String 
0000000385644a88 0.7MB 00000003856eee30 Microsoft.Win32.SafeHandles.SafeWaitHandle 
00000003868ecbc0 0.7MB 00000003869a18a8 System.Byte[] 
00000003878d0330 0.5MB 0000000387950678 System.Threading.ReaderWriterLock 
0000000387951680 1.2MB 0000000387a84b18 Microsoft.Win32.SafeHandles.SafeTokenHandle 
0000000387e137d0 1.8MB 0000000387fdbb50 System.Security.SafeBSTRHandle 
0000000388175388 1.5MB 00000003882ed100 System.Threading.ReaderWriterLock 
00000003882ee108 0.8MB 00000003883b5b10 System.String 
00000003883c5c20 0.9MB 00000003884aa8d8 System.Byte[] 
00000003891fa318 1.7MB 00000003893a3e30 Microsoft.Win32.SafeHandles.SafeTokenHandle 
0000000389cafe00 0.7MB 0000000389d61ff0 System.Byte[] 
000000038a036238 1.0MB 000000038a135428 System.Net.ListenerAsyncResult

這裏是！address -summary的輸出。堆使用摘要顯示1.1 GB，但我不知道這是否是所有託管堆？

0:000> !address -summary 
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal 
Free         525  7fa`04208000 ( 7.977 Tb)   99.71% 
<unknown>        917  5`8f56a000 ( 22.240 Gb) 92.92% 0.27% 
Heap         204  0`4b5af000 ( 1.177 Gb) 4.92% 0.01% 
Image         2327  0`12fc5000 (303.770 Mb) 1.24% 0.00% 
Stack         701  0`0df80000 (223.500 Mb) 0.91% 0.00% 
TEB          229  0`001ca000 ( 1.789 Mb) 0.01% 0.00% 
Other         19  0`001bf000 ( 1.746 Mb) 0.01% 0.00% 
PEB          1  0`00001000 ( 4.000 kb) 0.00% 0.00% 

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal 
MEM_PRIVATE       1717  5`e6543000 ( 23.599 Gb) 98.59% 0.29% 
MEM_IMAGE        2627  0`140dc000 (320.859 Mb) 1.31% 0.00% 
MEM_MAPPED        54  0`017c9000 ( 23.785 Mb) 0.10% 0.00% 

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal 
MEM_FREE        525  7fa`04208000 ( 7.977 Tb)   99.71% 
MEM_RESERVE        736  5`2ba70000 ( 20.682 Gb) 86.41% 0.25% 
MEM_COMMIT        3662  0`d0378000 ( 3.253 Gb) 13.59% 0.04% 

--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal 
PAGE_READWRITE       1590  0`babd4000 ( 2.918 Gb) 12.19% 0.04% 
PAGE_EXECUTE_READ      260  0`0f1ba000 (241.727 Mb) 0.99% 0.00% 
PAGE_READONLY       756  0`0376d000 ( 55.426 Mb) 0.23% 0.00% 
PAGE_WRITECOPY       561  0`01f24000 ( 31.141 Mb) 0.13% 0.00% 
PAGE_EXECUTE_READWRITE     180  0`008bd000 ( 8.738 Mb) 0.04% 0.00% 
PAGE_READWRITE|PAGE_GUARD    229  0`0043f000 ( 4.246 Mb) 0.02% 0.00% 
PAGE_EXECUTE_WRITECOPY     85  0`0025a000 ( 2.352 Mb) 0.01% 0.00% 
PAGE_EXECUTE        1  0`00003000 ( 12.000 kb) 0.00% 0.00% 

--- Largest Region by Usage ----------- Base Address -------- Region Size ---------- 
Free          5`ffff0000  7f8`93260000 ( 7.971 Tb) 
<unknown>         3`92f8f000  0`ed061000 ( 3.703 Gb) 
Heap          0`19010000  0`00fd0000 ( 15.813 Mb) 
Image         7fe`edfb9000  0`01368000 ( 19.406 Mb) 
Stack          0`0b8d0000  0`000fc000 (1008.000 kb) 
TEB          7ff`ffbd4000  0`00002000 ( 8.000 kb) 
Other          0`008a0000  0`00181000 ( 1.504 Mb) 
PEB          7ff`fffdf000  0`00001000 ( 4.000 kb)

最後如果運行！eeheap -gc，它在所有四個GC堆中顯示〜1.6GB。

0:000> !EEHeap -gc 

Number of GC Heaps: 4 
------------------------------ 
Heap 0 (00000000002d8aa0) 
generation 0 starts at 0x000000008ff94830 
generation 1 starts at 0x000000008f1157e8 
generation 2 starts at 0x000000007fff1000 
ephemeral segment allocation context: none 
segment  begin allocated size 
000000007fff0000 000000007fff1000 00000000935cc580 0x135db580(324908416) 
Large object heap starts at 0x000000047fff1000 
segment  begin allocated size 
000000047fff0000 000000047fff1000 0000000484d38270 0x4d47270(81031792) 
Heap Size:    Size: 0x183227f0 (405940208) bytes. 
------------------------------ 
Heap 1 (0000000000abcf00) 
generation 0 starts at 0x0000000190b5f3f8 
generation 1 starts at 0x000000018fcb1988 
generation 2 starts at 0x000000017fff1000 
ephemeral segment allocation context: none 
segment  begin allocated size 
000000017fff0000 000000017fff1000 0000000193ee36f8 0x13ef26f8(334440184) 
Large object heap starts at 0x000000048fff1000 
segment  begin allocated size 
000000048fff0000 000000048fff1000 00000004960eae48 0x60f9e48(101686856) 
Heap Size:    Size: 0x19fec540 (436127040) bytes. 
------------------------------ 
Heap 2 (0000000000ac78b0) 
generation 0 starts at 0x000000028f89f588 
generation 1 starts at 0x000000028e83ca90 
generation 2 starts at 0x000000027fff1000 
ephemeral segment allocation context: none 
segment  begin allocated size 
000000027fff0000 000000027fff1000 0000000292bf43d0 0x12c033d0(314586064) 
Large object heap starts at 0x000000049fff1000 
segment  begin allocated size 
000000049fff0000 000000049fff1000 00000004a5b90b78 0x5b9fb78(96074616) 
Heap Size:    Size: 0x187a2f48 (410660680) bytes. 
------------------------------ 
Heap 3 (0000000000ad2c00) 
generation 0 starts at 0x000000038ecddd18 
generation 1 starts at 0x000000038dcb9ec8 
generation 2 starts at 0x000000037fff1000 
ephemeral segment allocation context: none 
segment  begin allocated size 
000000037fff0000 000000037fff1000 00000003925e93b8 0x125f83b8(308249528) 
Large object heap starts at 0x00000004afff1000 
segment  begin allocated size 
00000004afff0000 00000004afff1000 00000004b55a61e8 0x55b51e8(89870824) 
Heap Size:    Size: 0x17bad5a0 (398120352) bytes. 
------------------------------ 
GC Heap Size:   Size: 0x6265f218 (1650848280) bytes.

我有兩個問題。
1.是否有無法獲得！dumpheap -stat命令中列出的所有對象大小的總和。
2.有無論如何驗證GC堆大小與來自！dumpheap -stat的所有對象的總大小相匹配，以便我可以確定所有對象都被佔用了嗎？

來源

2014-09-04 Paul Snow

您是否爲非託管資源調用* Dispose（）*方法（或者，使用*語句在*內使用範圍）？ – 2014-09-04 02:23:53

Windbg是一個體面的.NET內存分析器的替代品。但是，嘿，120 MB的事件處理程序，看起來沒有更進一步。與WMI相關聯，死鎖的終結器線程是標準解釋。 – 2014-09-04 12:54:02

感謝漢斯。我如何進一步調查。 syncblk不顯示任何正在其他線程上等待的線程 – 2014-09-04 13:54:33

首先，address -summary只顯示由CreateHeap（）函數創建的堆，它不是.NET。 .NET使用它自己的堆，並在輸出中顯示爲<unknown>。

接下來，你忘了添加大小爲520 MB的「免費」對象。這些是.NET堆中的一個地方，.NET對象早些時候已經在那裏，但之後被垃圾收集。這個可用空間可能會或可能不會在稍後返回給操作系統。在執行該命令時，它已被.NET內存管理器使用，但該管理員認爲它是免費的。從操作系統的角度來看，該內存仍在使用中（保留或提交，但不是免費的）。

第三我假設這是一個錯誤：總體GC堆大小爲1650848280，這是1.6 GB，而不是160 GB。否則它將與22GB的<unknown>號碼相矛盾。

但是有一個問題是開放的：如果<unknown>是22 GB，但只有1.6 GB由.NET管理，其他組件則直接調用VirtualAlloc()。這很不尋常，因爲VirtualAlloc()的粒度非常粗糙，所以沒有人使用它。只要你知道你在用這些大塊的內存做什麼，就可能有用例。

關於您的問題：請參閱@SteveJohnson的答案。我不確認內存碎片是由繁重的異步I/O造成的。這可能是一個原因，但也有其他原因，例如固定對象（通常與一些本地的東西一起）。不要忘記區分小對象堆碎片和大對象堆碎片。

更新：

據我所知，你不能從誰分配的虛擬內存轉儲弄清楚。您可以通過在VirtualAlloc（）上設置斷點並將callstack輸出到輸出文件並稍後檢查不同的調用堆棧來實現。我從來沒有在實踐中這樣做，但以下應該是一個起點：

.logopen virtualalloc.log 
bp Kernel32!VirtualAlloc ".echo ANALYZE>;k;.echo <ANALYZE;g" 
bp Kernel32!VirtualAllocEx ".echo ANALYZE>;k;.echo <ANALYZE;g" 
g

這將爲VirtualAlloc創建一個斷點。命中時，它將callstack寫入一個開始標記和一個結束標記，因此輸出在會話之後更容易解析。它會立即繼續，以便您的應用程序有望不受超時影響。

另一種方法可能是Rohitab API monitor和VirtualAlloc過濾器。您可以在系統服務/內存管理/虛擬內存/ Kernel32.dll中找到VirtualAlloc和VirtualAllocEx。不幸的是，文件格式未打開，因此您無法使用工具分析結果。

來源

2014-09-04 10:22:32

謝謝。你是對的，它是1.6GB，我已經做了更正。因此，如果22GB是託管堆和僅佔用1.6 GB的GC，我怎麼才能找到剩餘20GB的對象呢？ – 2014-09-04 10:58:43

@PaulSnow：並不是說有物體。基本上，這只是一塊內存（byte []），任何請求它的人都可以用它做什麼。我已經更新了我的答案，以便在實時會話中對此進行調試。 – 2014-09-04 11:35:13

1 - 不，但你可以接近！sosex.dumpgen 0 -stat，！sosex.dumpgen 1 -stat，！sosex.dumpgen 2 -stat和！sosex.dumpgen 3 -stat（這是LOH ）。這些命令中的每一個都會爲您提供每代中所有對象的總大小。

2 - 我目前沒有調試程序，但我認爲如果將！eeheap -gc中的所有段大小相加，則應該接近所有對象的總大小。！sosex.dumpgen也爲您提供了生成的總大小（段大小），因此它應該與eeheap -gc一樣。

看起來你有大量的堆碎片，如520,724,414字節的自由對象所示。這通常是由繁重的異步I/O造成的。

來源

2014-09-04 02:28:39

謝謝，我意識到大量的自由對象，但只有在LOH中才會出現問題。我正在調查那部分。你能否提供任何關於異步I/O如何導致碎片的鏈接。 – 2014-09-04 02:36:17

我沒有鏈接，但在大多數我調試過的堆碎片情況下，罪魁禍首都是異步I/O。將字節[]傳遞給異步I/O方法時，該緩衝區必須在傳遞到系統之前進行固定。異步I/O不是堆碎片的唯一原因，但正如我所說，這是我經驗中的一個常見問題。 – 2014-09-04 15:23:43

管理堆大小及其中的所有對象的帳戶

回答

相關問題