windbg分析一次大查询导致的内存暴涨

　　项目上反馈了一个问题，就是在生产环境上，用户正常使用的过程中，出现了服务器内存突然暴涨，客户有点慌，想找下原因。

　　讲道理，内存如果是缓慢上涨一直不释放的话，应该是存在内存泄漏的，这种排查起来比较困难，还得找开发一块看；但像这种突然暴涨的，肯定是把某些大对象放到内存里了，而最有可能的，就是大查询了，比如把几百万数据查出来这种，但这种一般等用户用完这个功能内存就会降下来。

　　环境：IIS+.net framework。发现是w3wp进程一直在涨内存，也就是iis，确实是程序的锅。

　　分析内存问题的话，一般是在持续上涨的过程中，多抓几个dump，看看哪些对象没释放，便于分析，这次用户只抓了一个dump，要不然太大了，传到我本机也费事。

　　那就开始分析吧。

　　首先找了个本地测试环境，用windbg加载dump，加载分析文件，幸运的是，.loadby sos clr一次成功了，后续分析都没啥问题，不用再从客户那边拷贝sos，clr这些文件；

　　这是用户正常业务场景的dump，也不知道当时多少人用，都在干什么，既然是内存问题，先看下内存中的对象情况吧：

　　!dumpheap -stat

　　果不其然，出现了DataRow的影子，估计是有个大查询没跑了。但是是什么场景？哪个sql？查出来多少数据？这个得继续分析了。

　　需要注意的是，抓这个dump的时候，内存3g多，dump大小也3g多，但是DataRow这个对象总共才46M，为什么要看这个对象，不看其他的呢？

　　要知道，分析的话，从占用大的对象开始分析是没问题，但是得看这个对象是不是比较特殊，像是上边占用最高的是string，1g多，但是string太普遍了，数量多也正常，而且不好分析，但DataRow这个肯定是访问数据库了，这种对象好分析。

　　再就是，为什么才46M，这个涉及到托管内存和非托管内存了。c#是基于.net的高级编程语言，所谓的托管，其实是指内存的托管，就是当写代码需要new一个新对象的时候，是不需要考虑内存申请与销毁的，.net自动给你做了，所以，当你抓了一个6g的dump，可能里边的托管内存才2g，剩余4g非托管内存里的东西从windbg是看不到的，非托管内存的增长，肯定是由托管代码引起的，所以这个地方虽然DataRow只有46M，但是由这个引起的内存增长是不可知的。

　　那接下来就看看工作线程数和堆栈吧，对当时的业务场景、使用人数大概有个了解：

　　!threads -special

　　工作线程数不是很多，说明同时使用的人不多，应该不会有太大的压力，所以可能是某一个或者某几个线程引起的，那就看下堆栈情况，大致了解下使用场景，猜一下是哪个场景引起的：

　　~* e!clrstack    打印下所有线程的堆栈

　　本来工作线程就不多，有业务含义并且和数据库相关的堆栈就更少了，看了下，大致有三个场景：

　　一个貌似是在判断权限：

　　一个貌似是个财务的往来单位查询：

　　还有一个貌似是财务的凭证查询：

　　具体是哪个引起的就得继续分析了，可以分别进入这三个线程，看下线程里的对象情况。

　　比如，切换到往来单位查询的那个线程里（线程id是107），然后通过!dso命令查看下当前线程的对象：

　　~107 s

　　!dso

　　直接就看到一个sql了，看下这个线程里的DataRow吧，看看它是不是它的锅：

　　!do 0000006231d5af28

　　查看下所在的DataTable信息：

　　!do 0000006027566878 

　　从elementColumnCount能看出来，当前是查询出来了89列；看的时候，要看下Type列，看看当前的对象类型，哪些是你需要和关注的。

　　然后再看recordManager，看下查询出来的记录信息，也就是行信息：

　　!do 0000006027566b08 

　　recordCapacity，行容量，524288，即查询出来的行为52w。

　　至此，应该明了了，就是往来单位查询场景，上边的那个sql（当然也可以通过!dso中sqlCommand对象查看Text，确认具体的sql），查询出来了52w行，89列，导致的内存暴涨。

　　后来通过跟开发与用户确认，确实是这个查询界面上，没有选具体的单位，然后关联了一张600w数据的表，最终查出了52w行数据导致的。实际用户的业务场景是需要具体单位的，这种场景没做跨单位查询的权限控制，用户又恰巧没选单位，所以出现了这个问题。后来开发把单位加了必选，该问题解决。