当前位置: 首页 > 知识库问答 >
问题:

对托管堆大小和其中的所有对象进行核算

巫马泓
2023-03-14

我正在调查我的应用程序的高内存消耗问题。记忆一直在上升,我想知道所有的记忆是在哪里消耗的。我有一个3GB大小的转储文件。

这是输出的命令。整个列表很长,但我只是想向您展示最大的项目,如字节[](195 MB),标识变更事件处理程序(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

这是我们的输出!地址-摘要。堆使用情况摘要显示1.1GB,尽管我不知道这是否都是托管堆?

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。是否有任何方式得到所有对象大小的总和中列出的!Dumphap-stat命令。
2。是否有任何方式验证GC堆大小与所有对象的总大小匹配!Dumphap-stat,这样我就可以确定我所有的对象都占了?

共有2个答案

曹兴贤
2023-03-14

1-不,但你可以接近!索塞克斯。dumpgen 0-统计!索塞克斯。dumpgen 1-统计!索塞克斯。dumpgen 2-统计和!索塞克斯。dumpgen 3-stat(这是LOH)。这些命令中的每一个都将为您提供每一代中所有对象的总大小。

2-我现在手头没有调试器,但我认为如果你把所有的段大小加起来!eeheap-gc,你应该接近所有对象的总大小!索塞克斯。dumpgen还提供了生成的总大小(段大小),因此应该与您看到的匹配!eeheap-gc也是。

看起来您有大量的堆碎片,如520,724,414字节的空闲对象所示。这通常是由重度异步输入/输出引起的。

井轶
2023-03-14

首先,address-summary只显示由CreateHeap()函数创建的堆,而不是。网NET使用自己的堆,并在输出中显示为

接下来,您忘记添加大小为520 MB的“自由”对象。这些是. NET堆中的位置。NET对象在更早的时候就在那里,但后来被垃圾收集了。这个可用空间可能会也可能不会稍后还给操作系统。在执行命令时,它正在被。NET内存管理器使用,但该管理器认为它是免费的。从操作系统的角度来看,该内存仍在使用中(保留或提交,但不是免费的)。

第三,我认为这是一个错误:总的GC堆大小是1650848280,是1.6GB,而不是160GB。否则它将与

但有一个问题是开放的:如果

关于你的问题:请参见@SteveJohnson的回答。我不确认内存碎片是由重度异步输入/输出引起的。这可能是一个原因,但也有其他原因,例如固定对象(通常与一些本地东西结合在一起)。不要忘记区分小对象堆碎片和大对象堆碎片。

更新:

据我所知,您无法从转储中找出谁分配了虚拟内存。您可以通过在VirtualAlloc()上设置断点并将调用堆栈打印到输出文件中,然后检查不同的调用堆栈来做到这一点。我在实践中从未这样做过,但以下应该是一个起点:

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

这将为VirtualAlloc创建一个断点。当命中时,它会用一个开始标记和一个结束标记写入调用堆栈,因此在会话结束后更容易解析输出。它会立即继续,希望您的应用程序不会受到超时的影响。

另一种方法是Rohitab API监控和过滤VirtualAlloc。您可以在System Services/Memory Management/Virtual Memory/Kernel32中找到VirtualAlloc和VirtualAllocEx。dll。不幸的是,文件格式未打开,因此无法使用工具分析结果。

 类似资料:
  • 问题内容: 如果设置最大Java堆大小,那么单个对象可能的最大大小是多少? 假设我的应用程序只有一个类,而我正在创建一个对象。 该对象有大约大小限制吗? 我的课看起来像下面的课: 注意 正如我提到的JVM堆大小一样,我要求定量地回答。 问题答案: 理论上最大的Java对象(如果您有足够大的堆)将是带有2 31-1个元素的Java对象。那是16Gb。 但是,对于给定的堆大小,您将能够创建的最大对象取

  • 内核对象管理接口 结构体 struct   rt_object   内核对象基类控制块 更多...   struct   rt_object_information   内核对象信息 更多...   宏定义 #define  RT_OBJECT_FLAG_MODULE   0x80   动态模块对象标志   类型定义 typedef struct rt_object *  rt_object_t

  • 问题内容: 好的,这是一个棘手的问题。我有一套清单。我想按顺序对集合中的对象进行排序。 想象每个场景都压抑着学校的一堂课。每个集合包含人物对象。人员对象具有名称的字符串值。在遍历并写下来之前,我想按名称排列集合中的人物。 是否有任何使用或类似的方法可以实现此目的? 我确实知道班上2个以上的孩子可能使用相同的名字,但请忽略此 问题答案: A 没有 排序的 概念,因为它是一个集合。 您可以使用按类实现

  • 问题内容: 我想记录一个对象占用一个项目的内存量(以字节为单位)(我正在比较数据结构的大小),并且似乎没有方法可以在Java中完成。据说C / C ++有方法,但这在Java中不存在。我尝试在创建对象之前和之后记录JVM中的可用内存,然后记录差异,但是无论结构中元素的数量如何,它只会给出0或131304,并且两者之间什么都没有。请帮助! 问题答案: 你可以使用该软件包: http://docs.o

  • 了解如何在 Adobe XD 中选择对象、调整对象的大小和旋转对象。 选择对象 您需要先将一个对象与其周围的对象区分开来,然后才能修改该对象。只需选择该对象,即可加以区分。在您选择了对象或者对象的一部分之后,您可以根据需要对其进行编辑。 单击选择工具,当光标变为指针时,单击对象或对象组。  如需选择多个对象,请使用选择工具在对象周围绘制选框,或按住 Shift 键并单击对象。  如需选择组中的对象

  • 问题内容: 是否有可能在Java中获得对对象的所有引用。 我需要检查的是对象是否删除了所有的回调订阅。 谢谢 问题答案: 这可以通过JVMTI实现,并且通常由堆分析器完成。但是,它不能在Java内部完成。