Windbg 分析内存上涨

症状:

上次一站点发布后,发现服务器内存持续上涨。正常本地缓存占了4-5个G ,使用内存直接涨到20G后应用程序池重启。

检查代码后发现,没有什么内存泄漏的地方。最后还是找来DUMP文件排查原因。

!dumpheap –stat       查看当前所有托管类型的统计信息

System.Threading.ReaderWriterCount 占了七个G。这是个读写锁, 有一亿多个对象。

!dumpheap –mt  000007fef32fa770        查看函数表地址中的各个对象信息

然后查看其中一个对象

!gcroot  0xooooooo1f27e03b8 查找对象的根,需要很久的时间

这个是ReaderWriterLockSlim 的内部对象。

继续查找ReaderWriterLockSlim的根

!gcroot  00000001d09379d8

这是用引用框架DLL 内部的方法。

应该是什么原因造成创建了大量ReaderWriterLockSlim对象又没有释放。

找到原代码后发现,是由于注册了一个HttpModule 对每个不重复的访问目录进行记录,这个过程会对每个目录分配一个读写锁。

正好,上次另一个客端的更新,每次访问都加上随机后缀目录。造成大量的读写锁。

禁掉DLL 的这个功能后,问题解决。

Windbg 分析内存上涨

时间: 2024-10-16 22:11:36

Windbg 分析内存上涨的相关文章

Windbg 分析CPU上涨

症状: 下班前,收到报警邮件.一个应用的两台服务器CPU 过高.打开监控一看CPU都100了.没找到原因之前,先抓好DUMP 然后重启应用程序池. !threadpool 可以看到CPU 利用率 !runaway 查看运行的线程和运行时间 解决CPU 高的问题,应该从运行的线程上分析.分析它们都在干什么,哪个线程一直占用CPU运行时间 ~threadid s  切换到运行时间最长的几个线程 k   显示当前线程的call stack 发现都是在GC线程(SVR::gc_heap::gc_thre

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

项目上反馈了一个问题,就是在生产环境上,用户正常使用的过程中,出现了服务器内存突然暴涨,客户有点慌,想找下原因. 讲道理,内存如果是缓慢上涨一直不释放的话,应该是存在内存泄漏的,这种排查起来比较困难,还得找开发一块看:但像这种突然暴涨的,肯定是把某些大对象放到内存里了,而最有可能的,就是大查询了,比如把几百万数据查出来这种,但这种一般等用户用完这个功能内存就会降下来. 环境:IIS+.net framework.发现是w3wp进程一直在涨内存,也就是iis,确实是程序的锅. 分析内存问题的话,一

Windbg分析高内存占用问题

1. 问题简介 最近产品发布大版本补丁更新,一商超客户升级后,反馈系统经常奔溃,导致超市的收银系统无法正常收银,现场排队付款的顾客更是抱怨声声.为了缓解现场的情况, 客户都是手动回收IIS应用程序池才能解决. 这样的后果是很严重的,接到反馈,第一时间想到的是加内存吧,这样最快.但是客户从8G-->16G-->32G,只是延长了每次奔溃的时间,但是并没有解决系统卡顿的问题.到这里,也基本猜测了问题所在了,肯定是什么东西一直在吃内存且得不到释放.这种问题,也就只能打Dump分析了. 2. 打Dum

Protobuf使用不当导致的程序内存上涨问题

protocol buffers[1]是google提供的一种将结构化数据进行序列化和反序列化的方法,其优点是语言中立,平台中立,可扩展性好,目前在google内部大量用于数据存储,通讯协议等方面.PB在功能上类似XML,但是序列化后的数据更小,解析更快,使用上更简单.用户只要按照proto语法在.proto文件中定义好数据的结构,就可以使用PB提供的工具(protoc)自动生成处理数据的代码,使用这些代码就能在程序中方便的通过各种数据流读写数据.PB目前支持Java, C++和Python3种

揪出“凶手”——实战WinDbg分析电脑蓝屏原因

http://www.appinn.com/blue-screen-search-code/ 蓝屏代码查询器 – 找出蓝屏的元凶 11 文章标签: windows / 系统 / 蓝屏. 蓝屏代码查询器可以帮你查出引起蓝屏的故障原因并可以到微软知识库中查询解决方案,和之前的 BlueScreenView 配合是很好的蓝屏故障排除组合.@Appinn 使用时只需填入错误代码的简写即可,另外在支持中心中有关于蓝屏原因分析的文章链接,有兴趣的童鞋可以去看看..  官方网站 | 来自小众软件 http:/

使用Windbg分析蓝屏原因

序言:     当电脑频繁蓝屏时我们需要软件来查找蓝屏原因,此时可以使用Windbg软件对蓝屏文件进行分析查找原因. 工具:     1.WinDbg软件,有两种版本,可以参考我的上一篇文章:安装与配置windbg的symbol(符号) 方法/步骤:     1.首先我们要保证我们设置了蓝屏转储,这样当电脑蓝屏时,系统会以.dmp文件方式保留蓝屏故障原因,我们需要查询是否设置内存转储和蓝屏文件存放位置.右键单击桌面计算机图标--选择属性,单击高级系统设置,在启动和故障恢复栏中单击设置,在写入调试

使用Android Studio分析内存问题

大家好!本人是即将毕业学生一枚,闲暇时间经常看大神们写的博客学到很多东西.最近在做毕业设计的时候遇到一些问题,然后把自己的问题和解决方法总结一下,有不对的地方希望大家多多包涵,提出批评与指导. 这篇博文主要介绍使用AndroidStudio对内存进行分析和跟踪,还有就是从源码角度解决ImageLoader引起的OOM问题. 我正在做的项目使用到了ImageLoader来加载图片,我也是第一次使用,就拿来直接用了.写完的代码运行很正常的加载图片,并没有发现什么问题.但是在测试的时候发现了问题.当多

Android最佳性能实践(二)——分析内存的使用情况

转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/42238633 虽说现在的手机内存都已经非常大了,但是我们大家都知道,系统是不可能将所有的内存都分配给我们的应用程序的.没错,每个程序都会有可使用的内存上限,这被称为堆大小(Heap Size).不同的手机,堆大小也不尽相同,随着现在硬件设备不断提高,堆大小也已经由Nexus One时的32MB,变成了Nexus 5时的192MB.如果大家想要知道自己手机的堆大小是多少,可以调用如

Android Studio和MAT结合使用来分析内存问题

Android开发中时常会遇到内存泄漏的问题,而Android系统对单个App又有一定的内存限制,此值可以通过一下方式获取: ActivityManager am = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE); int memoryClass = am.getMemoryClass(); 上述代码中momeryClass的值可以当做每个App的内存限制.这个值根据不同的设备厂商都是不一样的,比如我的模拟器的值是32M,