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

Posted invokerr

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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行数据导致的。实际用户的业务场景是需要具体单位的,这种场景没做跨单位查询的权限控制,用户又恰巧没选单位,所以出现了这个问题。后来开发把单位加了必选,该问题解决。

以上是关于windbg分析一次大查询导致的内存暴涨的主要内容,如果未能解决你的问题,请参考以下文章

记一次 .NET某家装ERP系统 内存暴涨分析

记一次 .NET某家装ERP系统 内存暴涨分析

记一次 .NET 某三甲医院HIS系统 内存暴涨分析

记录一次生产环境Net Core应用内存暴涨导致OOM的排查过程

记一次 .NET某家装ERP 内存暴涨分析

记一次 .NET 某WMS仓储打单系统 内存暴涨分析