在一次上线过程中iis内存飙升,随后跟运维要到站点的dump文件,使用windbg分析了clr的内存分配,找到了问题的症结,先记录如下:

使用windbg加载dump文件

1.打开windbg,File->Open Crush Dump,打开dump文件;
2.设置符号路径和站点发布文件路径
.sympath C:\MyCodesSymbols*SRV*C:\MyLocalSymbols*http://msdl.microsoft.com/download/symbols:C:\Users\Administrator\Desktop\symbol  
其中,C:\Users\Administrator\Desktop\symbol是pdb文件所在目录,C:\MyCodesSymbols和C:\MyLocalSymbols均为新建文件夹存放符号文件
3.加载sos.dll和clr.dll
.load sos.dll,clr.dll文件所在的目录(可以拷贝这两个dll放在pdb文件目录下)
4.加载pdb文件 .symfix
5.加载.reload
6.输入命令.loadby sos clr
 
使用windbg命令查看堆内存
1.使用命令!dumpheap -stat 根据内存大小排序查看堆上的对象,查看占用内存比较高的对象和数组等,通过添加 -min 或者 -max 指定最小或者最大size的对象,首次执行这个命令不要添加 -min参数筛选,因为有可能就是一些小的对象比较多引起的内存问题。

2.使用!dumpheap -mt命令查看mt(method table)中的对象地址,上图的第一列为mt,查看指定的MT并显示出Address

!dumpheap -mt 000007fe9a25ebe8

第一列为对象地址(address),可以看到mt的statistic

3.进入这个地址查看具体的对象 !do 000000048a0eb1b0

4.查看对象引用 !gcroot 000000048a0eb1b0

5.根据上图中的线程线程信息定位线程ID,进入线程

!threads命令查看工作的线程,71为线程ID

6.进入71线程:~71s,下图所示已经进入71线程

7.使用!clrstack 命令查看该线程的堆栈信息

上图可以清晰的看到大的对象经过了哪些方法的调用,再结合代码,可以定位出问题。

附录(windbg命令)

内存状态:

!EEHeap -GC 显示托管堆统计信息
!EEHeap -loader 显示加载程序数据结构统计信息
!DumpHeap -stat 显示垃托管堆各类型统计信息
!DumpHeap -type Free -stat 显示所有碎片类型统计信息
!DumpHeap -type System.String -min 150 -max 200 显示所有System.String类型 -min -max 字节统计信息
!DumpHeap -min 85000 -stat 显示大对象统计信息
!DumpHeap -mt 选项仅列出与指定的 MethodTable 结构对应的那些对象
!DumpHeap -mt 00000000022245b0 -min 85000 查看MT 00000000022245b0中大对象
!DumpHeap -stat 023e1000 033db630 按地址统计
!DumpArray 显示数组对象
!DumpObj (!do) 显示有关指定地址处的对象的信息
!ObjSize 显示指定对象的大小
!DumpStackObjects (!dso) 显示在当前线程内找到的所有托管对象
!GCRoot 显示有关对指定地址处的对象的引用(或根)的信息。
!CLRUsage 显示托管堆统计信息(GC堆大小,提交内存,虚拟内存),psscor4的扩展命令
!DumpMT 显示有关指定地址处的方法表的信息。
!DumpMT -MD 显示有关指定地址处的方法表所有方法的列表。
!address -summary 显示最大可用区域
!vmstat 最大可用区域是 MAXIMUM 列中的最大值

线程调用:

!ThreadPool 显示有关托管线程池的信息,包括队列中工作请求的数目、完成端口线程的数目和计时器的数目
!Threads 显示进程中的所有托管线程
!Threads -live 选项显示与活动线程关联的线程
!Threads -pecial 选项显示由 CLR 创建的所有特殊线程
!ThreadState 显示线程的状态。 value 参数为 Threads 报告输出中的 State 字段的值。
~54s 转到54线程
!CLRStack 提供当前托管代码的堆栈跟踪。
!CLRStack -p 选项显示托管函数的参数。
!CLRStack -l 选项显示有关帧中的局部变量的信息。
!DumpStack 显示堆栈跟踪 包括非托管。 
!DumpStack -EE 命令仅显示托管函数。
!EEStack 对一个进程中的所有线程运行 DumpStack 命令。
k 显示当前线程的call stack
kb 显示当前线程的call stack
~*kb 显示所有线程的call stack 可以 寻找线程中触发GC的函数(mscorwks!SVR::GCHeap::GarbageCollectGeneration)
!ASPXPages 显示当前处理的HttpContext,psscor4的扩展命令
!SyncBlk 显示同步块

其它:
!runaway 显示线程cpu时间
vertarget 查看系统运行时间
!PrintException (!pe) 显示在当前线程上引发的最后一个异常
!address 命令显示某一地址上的页信息
!SaveModule 将加载到内存中指定地址的图像写入指定文件,lm 列出的
!SaveModule 081f0000 d:\\commandobject.dll 
!FinalizeQueue 显示所有已进行终结注册的对象。
!GCHandles 显示有关进程中的垃圾回收器句柄的统计信息。

S 可以搜索内存 在内存中搜索sina.com: s –u 0012ff40 L?8000000 “sina.com”
r 显示寄存器的信息
d 显示内存地址上的值 使用d命令显示esp寄存器指向的内存,默认为byte: d esp
用dd命令直接指定054efc14地址,第二个d表示用DWORD格式: dd 054efc14

域,程序集,类
!DumpDomain 枚举在指定的 AppDomain 对象地址内加载的每个 Assembly 对象。若在调用 DumpDomain 命令时不提供任何参数,则将列出过程中的所有 AppDomain 对象
!DumpAssembly 显示有关程序集的信息。DumpAssembly 命令将列出多个模块(如果存在)。
!DumpModule  显示有关指定地址处的模块的信息。 可以使用 DumpDomain 或 DumpAssembly 命令检索模块的地址
!DumpModule [-mt] 选项显示模块中定义的类型和模块所引用的类型
!FindAppDomain 确定指定地址处的对象的应用程序域

!IP2MD <Code address> 显示已 JIT 编译的代码中指定地址处的 MethodDesc 结构。
!DumpMD <MethodDesc address>
!U <MethodDesc address> | <Code address> 显示由方法的 MethodDesc 结构指针或方法体内的代码地址指定的托管方法的反汇编(带有批注)

 
 

iis站点内存泄漏问题分析的更多相关文章

  1. JVisualVM简介与内存泄漏实战分析

    JVisualVM简介与内存泄漏实战分析 学习了:https://blog.csdn.net/kl28978113/article/details/53817827

  2. 关于IIS站点最大并发量分析

    关于IIS站点最大并发量分析,会有如下这个疑问:IIS站点最大并发量是多少? 一般为:   IIS站点最大并发量=队列长度+进程数量[即最大工作进程数] 通过这个公式,可以基本评估出一个IIS站点的最 ...

  3. Day 18: 记filebeat内存泄漏问题分析及调优

    ELK 从发布5.0之后加入了beats套件之后,就改名叫做elastic stack了.beats是一组轻量级的软件,给我们提供了简便,快捷的方式来实时收集.丰富更多的数据用以支撑我们的分析.但由于 ...

  4. Java内存泄漏及分析

    对于内存泄漏,首先想到的是C语言,其实不然,java中也有各种的内存泄漏.对于java程序员,在虚拟即中,不需要为每一个新建对象去delete/free内存,不容易出现内存泄漏.但是,正 是由于这种机 ...

  5. AndroidStudio 内存泄漏的分析过程

    前言部分这次泄漏是自己代码写的太随意引起的,讲道理,代码写的太为所欲为了,导致有些问题根本就很难发现. 泄漏产生的原因,由于activity未被回收导致.这里给我们提出的一个警示,在使用上下文的时候, ...

  6. Yii2 框架跑脚本时内存泄漏问题分析

    现象 在跑 edu_ocr_img 表的归档时,每跑几万个数据,都会报一次内存耗尽 PHP Fatal error:  Allowed memory size of 134217728 bytesex ...

  7. Linux高级调试与优化——内存泄漏实战分析

    最近在整理Linux调试方面的文档,正好碰到了一个内存泄漏踩栈的问题,借此机会记录一下分析过程. 首先,发现问题之后,赶紧看一下产生coredump文件没有,果不其然,产生了coredump,果断上g ...

  8. JVisualVM 模拟一次内存泄漏场景分析

    首先贴一段内存泄漏的代码并且执行.(内存泄漏:GC回收不掉的实例对象) package com.example.demo.memoryLeakDemo; import com.example.demo ...

  9. 记一次内存泄漏DUMP分析

    自从进入一家创业公司以后,逐渐忙成狗,却无所收获,感觉自身的技术能力用武之地很少,工作生活都在业务逻辑中颠倒. 前些天线上服务内存吃紧,让运维把DUMP拿下来,分析一下聊以自慰. 先来统计一下大对象信 ...

随机推荐

  1. React 实践心得:react-redux 之 connect 方法详解

    Redux 是「React 全家桶」中极为重要的一员,它试图为 React 应用提供「可预测化的状态管理」机制. Redux 本身足够简单,除了 React,它还能够支持其他界面框架.所以如果要将 R ...

  2. WebSocket 的一些简单页面推送使用

    因为做通信项目的时候,需要实时获取每个分机的当前状态,发现websocket还不错,只是对浏览器的要求比较高, 针对特定用户推送消息,网上有一些 public class GetHttpSession ...

  3. MySQL性能优化之max_connections配置

    MySQL的最大连接数,增加该值增加mysqld 要求的文件描述符的数量.如果服务器的并发连接请求量比较大,建议调高此值,以增加并行连接数量,当然这建立在机器能支撑的情况下,因为如果连接数越多,介于M ...

  4. QTreeWidgetItem和QTreeWidgetItemIterator

    1.{ ui->treeWidget->setHeaderHidden(true); ui->treeWidget->clear(); QTreeWidgetItem *ima ...

  5. js中间件

    js中间件 当我们在编写业务代码时候,我们无法避免有些业务逻辑复杂而导致业务代码写得又长又乱,如果再加上时间紧凑情况下写出来的代码估计会更让人抓狂.以至于我们一直在寻求更好的架构设计和更好的代码设计, ...

  6. css hack解决方案

    现在大家做项目的时候估计很多都已经不怎么考虑兼容问题,大多数的公司都已经舍弃ie7.8了,都是从ie9+开始,所以说不会有那么多的兼容问题需要去解决了,但是由于本人力求完美的工作习惯,做项目的时候还是 ...

  7. 关于动态添加的html元素绑定的事件不生效的解决办法

    1.可以通过行内添加事件的方法,比如onclick="fn()"; 在js中写好方法名对应的方法就可以了,如果绑定方法的元素太多 2.jquery的on事件绑定 //on事件可以给 ...

  8. CentOS7.4 搭建和使用telnet

    1.先检查是否安装了telnet rpm -qa | grep telnet  //检查你的CentOS是否安装了telnet和telnet-server rpm -qa xinetd //检查你的C ...

  9. Groovy常用语法汇总

    基本语法 1.Grovvy的注释分为//和/**/和java的一样. 2.Grovvy语法可以不已分号结尾. 3.单引号,里面的内容严格的对应java中的String,不对$符号进行转义. def s ...

  10. tomcat时间与系统时间不一致问题

    我在部署应用到centos系统上的tomcat服务器中运行,发现操作系统的时间和tomcat中的访问日志的时间与系统时间不一致,但是查看当前操作系统的时区也是CST时区(中国标准时区). 查看系统的时 ...