WinDbg初始体验2，抓住不放的恶棍(OutOfMemory案例分析Ⅰ)

在上篇中，介绍了如何使用adplus来捕捉dump。我们可以使用这个命令：adplus -Crash -p 进程ID（或-IIS) -quiet -fullonfirst -o C:\dumps 。但是我们在哪里执行这段命令呢？在控制台命令行，切换到Windbg的安装目录下。然后执行上面的命令，当你监控的进程出现异常时，它就会捕捉到该进程的所有相关信息到dump文件中（前提是fullonfirst）。比如你的进程使用内存是1G，那么dump文件也会在1G左右。此时如果你想捕捉OutOfMemory的dump，不一定要等到这个异常出现后。你可以在内存到一定量的时候，去获取dump文件，基本的信息是一样的。

我捕捉到的dump文件是1.31 GB ，太大了，过了这个值，网站马上就Crash掉了。可能是由于服务器物理架构的原因，这个dump文件在我本机打不开，只有在服务器上调试了。打开dump文件，先来一段看不懂的提示：

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(39c.13c): CLR exception - code e0434f4d (first/second chance not available)
eax=0275f290 ebx=000d6848 ecx=00000000 edx=00000024 esi=0275f31c edi=e0434f4d
eip=7c80bee7 esp=0275f28c ebp=0275f2e0 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00200202
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for kernel32.dll -
kernel32!RaiseException+0x3c:
7c80bee7 5e              pop     esi

大概意思就是说：dump文件中有一个异常，各个寄存器的地址（应该是吧），找不到kernel32.dll的Symbol ，异常是由它引发，略略。

这时，我们在工作窗体中执行命令加载SOS.dll。.load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\SOS.dll

接下来我们就可以开始工作了，先执行命令：!eeheap -gc 看看托管堆上都放着些什么。

0:012> !eeheap -gc
PDB symbol for mscorwks.dll not loaded
Number of GC Heaps: 4
------------------------------
Heap 0 (000e28e0)
generation 0 starts at 0x6d110044
generation 1 starts at 0x6d110038
generation 2 starts at 0x02860038
ephemeral segment allocation context: none
 segment    begin allocated     size
1bd8c710 7b45382c  7b46a268 0x00016a3c(92732)
000f6b40 7a72c42c  7a74d308 0x00020edc(134876)
000eafb0 790d5588  790f4b38 0x0001f5b0(128432)
02860000 02860038  0685ea18 0x03ffe9e0(67103200)
2cca0000 2cca0038  30c9db38 0x03ffdb00(67099392)
44f30000 44f30038  48d01460 0x03dd1428(64820264)
6d110000 6d110038  6d112050 0x00002018(8216)
Large object heap starts at 0x12860038
 segment    begin allocated     size
12860000 12860038  14844b50 0x01fe4b18(33442584)
35c80000 35c80038  37b42920 0x01ec28e8(32254184)
Heap Size  0xfccdbe8(265083880)
------------------------------
Heap 1 (000e39b0)
generation 0 starts at 0x4ff2e1d4
generation 1 starts at 0x4ff2b4fc
generation 2 starts at 0x06860038
ephemeral segment allocation context: none
 segment    begin allocated     size
06860000 06860038  0a85db18 0x03ffdae0(67099360)
20aa0000 20aa0038  24a9ccb0 0x03ffcc78(67095672)
37d90000 37d90038  3bd8d500 0x03ffd4c8(67097800)
4efc0000 4efc0038  4ff321e0 0x00f721a8(16196008)
Large object heap starts at 0x14860038
 segment    begin allocated     size
14860000 14860038  16846380 0x01fe6348(33448776)
30d60000 30d60038  32d0e808 0x01fae7d0(33220560)
52fc0000 52fc0038  535b4598 0x005f4560(6243680)
Heap Size  0x114f2e40(290401856)
------------------------------
Heap 2 (000e4e70)
generation 0 starts at 0x447270a0
generation 1 starts at 0x447268f8
generation 2 starts at 0x0a860038
ephemeral segment allocation context: none
 segment    begin allocated     size
0a860000 0a860038  0e85f1e4 0x03fff1ac(67105196)
24ca0000 24ca0038  28c9f548 0x03fff510(67106064)
40730000 40730038  4472b0ac 0x03ffb074(67088500)
Large object heap starts at 0x16860038
 segment    begin allocated     size
16860000 16860038  188296c8 0x01fc9690(33330832)
1e890000 1e890038  20849ab0 0x01fb9a78(33266296)
4cfc0000 4cfc0038  4ef6aef0 0x01faaeb8(33205944)
Heap Size  0x11f276f0(301102832)
------------------------------
Heap 3 (000e63a8)
generation 0 starts at 0x40694068
generation 1 starts at 0x4069405c
generation 2 starts at 0x0e860038
ephemeral segment allocation context: none
 segment    begin allocated     size
0e860000 0e860038  1285df98 0x03ffdf60(67100512)
28ca0000 28ca0038  2cc9ef68 0x03ffef30(67104560)
3c730000 3c730038  4069a074 0x03f6a03c(66494524)
Large object heap starts at 0x18860038
 segment    begin allocated     size
18860000 18860038  1a85c5e0 0x01ffc5a8(33539496)
33c80000 33c80038  35c3b740 0x01fbb708(33273608)
56bb0000 56bb0038  57133f60 0x00583f28(5783336)
Heap Size  0x104a2aa4(273296036)
------------------------------
GC Heap Size  0x4358abbc(1129884604)

首先提示我们一下，存放mscorwks.dll symbol 的PDB文件不存在。然后告诉我们有4个GC拖管堆的存在。每个拖管堆都详细罗列出了每一个代龄堆的起始地址，以及每个堆上面存放的对象所占用内存空间。最后给我们统计了一下GC堆的大小，共有1129884604 bytes （1.1G左右），也就是说，当进程的内存大部分都被拖管堆给占用了。大对象有不少呢！接下来的命令是!dumpheap -min 85000 -stat 统计一下大对象的基本信息。

0:012> !dumpheap -min 85000 -stat
------------------------------
Heap 0
total 213 objects
------------------------------
Heap 1
total 207 objects
------------------------------
Heap 2
total 296 objects
------------------------------
Heap 3
total 230 objects
------------------------------
total 946 objects
Statistics:
      MT    Count    TotalSize Class Name
7912254c        6       746928 System.Object[]
7912677c       13      5889000 System.Single[]
79122610        3      9465840 System.Collections.Hashtable+bucket[]
000d88f0      105     36952120      Free
7912273c      335     37943440 System.Byte[]
79122414      484    219252000 System.Int32[]
Total 946 objects

好家伙，有946个大对象。而且单单整型数组就占用了200多M的内存，是什么东西在搞鬼呢？看看下面命令，这会是列出所有的大对象，不是得到统计信息：!dumpheap -min 85000

Heap 0
 Address       MT     Size
128823a0 7912273c   113264    
128a2818 7912273c   113264    
128be298 79122414   453000    
1292cc20 7912273c   113264    
12948690 000d88f0   107448 Free
12962c68 7912254c   124488    
129812b0 000d88f0   107296 Free
1299b5d0 79122414   453000    

.......

35ae0ed8 000d88f0   286800 Free
35b26f28 7912273c   113264    
35b42998 7912677c   453000    
35bb1338 79122414   453000    
35c1fcd0 7912273c   113264    
56bb0038 79122414   453000    
56c1e9c0 7912273c   113264    
56c3a430 000d88f0   339776 Free
56c8d370 79122414   453000    
56cfbd08 7912273c   113264    
56d17788 79122414   453000    
56d86110 79122414   453000   

total 230 objects
------------------------------
total 946 objects
Statistics:
      MT    Count    TotalSize Class Name
7912254c        6       746928 System.Object[]
7912677c       13      5889000 System.Single[]
79122610        3      9465840 System.Collections.Hashtable+bucket[]
000d88f0      105     36952120      Free
7912273c      335     37943440 System.Byte[]
79122414      484    219252000 System.Int32[]   
看出规律了吧？从Heap0到Heap3，都是存在这样的两种大小的对象：113264  和 453000  。有规律就好办事了，找一个出来看看，执行命令：!gcroot 0x34e9bee0

0:012> !gcroot 0x34e9bee0
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 12 OSTHread 13c
Scan Thread 18 OSTHread 1580
Scan Thread 19 OSTHread 1510
.....扫描太多线程了
DOMAIN(000FF798):HANDLE(Pinned):1aec11ec:Root:12870d18(System.Object[])->
070db534(Lucene.Net.Search.FieldSortedHitQueue+AnonymousClassCache)->
070db540(System.Collections.Hashtable)->
0634bfe4(System.Collections.Hashtable+bucket[])->
3e886dd4(System.Collections.Hashtable)->
3e886e0c(System.Collections.Hashtable+bucket[])->
3e887164(Lucene.Net.Search.FieldSortedHitQueue+AnonymousClassScoreDocComparator2)->
3e887154(Lucene.Net.Search.StringIndex)->
34e9bee0(System.Int32[])

看看，这都是什么东西啊？在程序中使用了Lucene.net，赶紧打开Reflector。查了查，看了看。我看到了缓存对象的实现，看到了每搜索一次都往缓存里加对象。但是我却没有看到缓存的过期和回收。怎么办呢？没有开关，没有配置。我只有通过源码找到Cache的实现，将它的public virtual object Get(IndexReader reader, object key)方法重写了，我不缓存了，不行吗！然后向Lucene.net报告这个情况。（也不知道这该不该认为是一个BUG呢，顺便说一下，Lucene.net已经有 2.1.0.2版本了，只不过是beta，还没有正式公布出来，我是在SVN服务器上看到的）。

缓存，是大多数内存问题的根源所在。有很多简单的缓存实现都是用一个Hashtable来缓存对象，但是它们却始终都没有做缓存过期的回收工作，甚至连过期策略都没有。这由不得让我想起了Enterprise Library的缓存，它有相当完善的缓存过期管理。但由于entlib使用和配置的问题，现在已基本不用了。现用的缓存基本也都使用HttpRumtime.Cache的缓存，虽然听很多人说使用它会有很多问题，比如自动释放。但是使用它也有很多好处呀，比如在web.config我们可以配置它的缓存策略，配置它要不定期回收，配置它可以使用的内存比例。总之，在一些场合，我们还是可以使用的。前提是，它适合我们，不会给你的程序带来很多的负面影响。使用Hashtable来缓存也是一样的，只要缓存项是有限的，那就可以用。

总算是找到了一个成功的找到了一个问题，兴奋之余接下来就是升级，看看效果了。但是，这个故事结束之后，看到的服务器的内存利用率还是暴涨，似乎没有任何改观？难道是我们的修改没有正确？预知详情，还请继续关注下一篇：《WinDbg初始体验3，剪不断的链条》

下一篇引用：WinDbg初始体验3，剪不断的链条

上一篇引用：WinDbg初始体验，问题来了怎么办？

阿不