內存不見了（.NET應用程序）

我創建了一個進程的完整轉儲（進程或其轉儲文件）需要〜7GB。該過程是WCF服務。啓動時需要約1.4GB，並在一段時間後增長，但從不超過2-3GB。永遠不會到今天。現在它幾乎需要所有的空閒內存。！內存不見了（.NET應用程序）

在WinDbg中運行dumpheap -stat命令時，我得到下一個：

000007fef929ac78 15038  4878720 System.Collections.Hashtable+bucket[] 
000007fe9c4d4d20 118818  7604352 BLL.EmailOptOutBLL 
000007fef92a0ec0 727949  17470776 System.RuntimeMethodHandle 
000007fef9287fe8 10794  17832144 System.Reflection.Emit.__FixupData[] 
000007fe9c6dc5c0 907500  36300000 ExactTargetEmail.etAPI.APIProperty 
000007fef927f1b8 409602  39034712 System.Object[] 
000007fe9c6d9858 302500  41140000 ExactTargetEmail.etAPI.ObjectExtension 
000007fef929f058 49141  52089645 System.Byte[] 
000007fef929aee0 2487200 152416116 System.String 
00000000013a6030  941 1601636252  Free

所有列出的對象的總規模約爲2.3GB

的eeheap -gc命令列出4堆用！總大小6.3GB

問題：剩下的7GB - 2.3GB = 4.7GB？我怎麼能找到他們在哪裏（在WinDbg或其他工具）？

！地址-summary

0:000> !address -summary 


Failed to map Heaps (error 80004005) 

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal 
Free         387  7fb`98d72000 ( 7.983 Tb)   99.79% 
<unclassified>       1141  4`53c8f000 ( 17.309 Gb) 98.28% 0.21% 
Image         2387  0`11ed5000 (286.832 Mb) 1.59% 0.00% 
Stack         141  0`0168c000 ( 22.547 Mb) 0.13% 0.00% 
TEB          47  0`0005e000 (376.000 kb) 0.00% 0.00% 
NlsTables         1  0`00023000 (140.000 kb) 0.00% 0.00% 
ActivationContextData      4  0`00007000 ( 28.000 kb) 0.00% 0.00% 
CsrSharedMemory       1  0`00005000 ( 20.000 kb) 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_PRIVATE        671  4`50a59000 ( 17.260 Gb) 98.00% 0.21% 
MEM_IMAGE        3014  0`15304000 (339.016 Mb) 1.88% 0.00% 
MEM_MAPPED        38  0`01521000 ( 21.129 Mb) 0.12% 0.00% 

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal 
MEM_FREE        387  7fb`98d72000 ( 7.983 Tb)   99.79% 
MEM_RESERVE        799  2`af232000 ( 10.737 Gb) 60.96% 0.13% 
MEM_COMMIT        2924  1`b804c000 ( 6.875 Gb) 39.04% 0.08% 

--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal 
PAGE_READWRITE       897  1`a2017000 ( 6.531 Gb) 37.08% 0.08% 
PAGE_EXECUTE_READ      333  0`103c9000 (259.785 Mb) 1.44% 0.00% 
PAGE_READONLY       899  0`03940000 ( 57.250 Mb) 0.32% 0.00% 
PAGE_WRITECOPY       527  0`01c95000 ( 28.582 Mb) 0.16% 0.00% 
PAGE_EXECUTE_READWRITE     132  0`003b9000 ( 3.723 Mb) 0.02% 0.00% 
PAGE_EXECUTE_WRITECOPY     88  0`00208000 ( 2.031 Mb) 0.01% 0.00% 
PAGE_READWRITE|PAGE_GUARD    47  0`000d2000 (840.000 kb) 0.00% 0.00% 
PAGE_EXECUTE        1  0`00004000 ( 16.000 kb) 0.00% 0.00% 

--- Largest Region by Usage ----------- Base Address -------- Region Size ---------- 
Free          5`3fa00000  7f9`5b0e0000 ( 7.974 Tb) 
<unclassified>       1`0a3ef000  0`f5611000 ( 3.834 Gb) 
Image         7fe`e7e9a000  0`01338000 ( 19.219 Mb) 
Stack          0`007c0000  0`0007b000 (492.000 kb) 
TEB          7ff`ffe9a000  0`00002000 ( 8.000 kb) 
NlsTables        7ff`fffb0000  0`00023000 (140.000 kb) 
ActivationContextData      0`00030000  0`00004000 ( 16.000 kb) 
CsrSharedMemory       0`7efe0000  0`00005000 ( 20.000 kb) 
PEB          7ff`fffdf000  0`00001000 ( 4.000 kb)

！eeheap -gc

0:000> !eeheap -gc 
Number of GC Heaps: 4 
------------------------------ 
Heap 0 (00000000013d4ad0) 
generation 0 starts at 0x00000001066b2868 
generation 1 starts at 0x00000001066984b8 
generation 2 starts at 0x00000000ffa01000 
ephemeral segment allocation context: none 
segment  begin allocated size 
00000000ffa00000 00000000ffa01000 00000001067ea940 0x6de9940(115251520) 
Large object heap starts at 0x00000004ffa01000 
segment  begin allocated size 
00000004ffa00000 00000004ffa01000 0000000509173080 0x9772080(158802048) 
Heap Size:    Size: 0x1055b9c0 (274053568) bytes. 
------------------------------ 
Heap 1 (00000000013d9960) 
generation 0 starts at 0x0000000203ef0168 
generation 1 starts at 0x0000000203d01f78 
generation 2 starts at 0x00000001ffa01000 
ephemeral segment allocation context: none 
segment  begin allocated size 
00000001ffa00000 00000001ffa01000 000000027c2af408 0x7c8ae408(2089477128) 
Large object heap starts at 0x000000050fa01000 
segment  begin allocated size 
000000050fa00000 000000050fa01000 000000050fa01018 0x18(24) 
Heap Size:    Size: 0x7c8ae420 (2089477152) bytes. 
------------------------------ 
Heap 2 (0000000001e48f90) 
generation 0 starts at 0x000000030552c398 
generation 1 starts at 0x00000003054a0920 
generation 2 starts at 0x00000002ffa01000 
ephemeral segment allocation context: none 
segment  begin allocated size 
00000002ffa00000 00000002ffa01000 0000000374600330 0x74bff330(1958736688) 
Large object heap starts at 0x000000051fa01000 
segment  begin allocated size 
000000051fa00000 000000051fa01000 000000051fd87130 0x386130(3694896) 
Heap Size:    Size: 0x74f85460 (1962431584) bytes. 
------------------------------ 
Heap 3 (0000000001e4bfa0) 
generation 0 starts at 0x00000004059eaa60 
generation 1 starts at 0x00000004057d3308 
generation 2 starts at 0x00000003ffa01000 
ephemeral segment allocation context: none 
segment  begin allocated size 
00000003ffa00000 00000003ffa01000 0000000471912bb8 0x71f11bb8(1911626680) 
Large object heap starts at 0x000000052fa01000 
segment  begin allocated size 
000000052fa00000 000000052fa01000 0000000534f2d468 0x552c468(89310312) 
Heap Size:    Size: 0x7743e020 (2000936992) bytes. 
------------------------------ 
GC Heap Size:   Size: 0x1791cd260 (6326899296) bytes.

來源

2014-12-03 Kamarey

！地址 - 總結將給你一個過程的概述。告訴我們輸出 – 2014-12-03 16:40:17

@Kjell Gunnar：在這裏。如果我們正在談論這個命令 - 7.9Tb是什麼意思？這不是TB，對不對？該機器沒有全部這些內存或磁盤 – Kamarey 2014-12-03 16:43:38

這是該進程的免費虛擬內存。 64位程序可以擁有8TB的虛擬內存。 – magicandre1981 2014-12-03 17:14:17

前面已經提到的，7.983 Tb的只是免費虛擬空間 IE空間（尚）用過的。

你！地址-summary顯示17 GB，並且錯誤「未能映射堆」是指原生堆包括在<未分類>

據我所知，您的17 GB包含

a) Native heaps, 
b) .NET heaps 
c) Areas allocated by VirtualAlloc 
d) Memory mapped files

.NET堆貢獻6 GB，剩下11 GB調查。爲了檢查本地堆，你可以嘗試使用：

!heap –s

，但如果他們是大大小可能不可靠，因爲它可能無法正常工作解決-summary無法歸類！您也可以嘗試：

!address 
    BaseAddress  EndAddress+1  RegionSize  Type  State     Protect    Usage 
------------------------------------------------------------------------------------------------------------------------ 
+  0`00000000  0`00010000  0`00010000    MEM_FREE PAGE_NOACCESS       Free  
+  0`00010000  0`00020000  0`00010000 MEM_MAPPED MEM_COMMIT PAGE_READWRITE      Heap  [ID: 1; Handle: 0000000000010000; Type: Segment] 
+  0`00020000  0`00021000  0`00001000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE      <unknown>

在未來很長的輸出準備（所以重定向到一個文件），在這裏你可以看到所有你的記憶地區和映射文件的文件名。

來源

2014-12-04 09:49:12

我期待您的轉儲文件接近17 GB（正如Kjell指出的），而不是7 GB。我不認爲你真的想在你的問題中使用7 GB，但我可能是錯的。查看this article以瞭解更多關於！dumpheap -summary中顯示的總大小。

什麼是相關的是，GC堆使用6.2 GB構成承諾內存的大部分（6.875 GB）。這是你最可能關心的。您的應用程序使用4個GC堆，其中堆0比其他3個（使用接近2 GB）稍小（〜274 MB）。如果你的應用沒有內存壓力，那麼花時間垃圾收集可能效率不高。

顯示您的！地址和！堆輸出可能有助於理解爲什麼有10.737 Gb內存保留。

來源

2016-09-28 18:45:59

內存不見了（.NET應用程序）

回答

相關問題