Windbg程序调试系列2-内存泄露问题

小鱼儿 2021-10-29 15:06 459阅读 0赞

上篇文章给大家解释了Windbg的基本命令和说明，这一篇给大家介绍内存泄露场景的问题分析。

**文章大纲：**

1.  描述问题背景和现象
2.  确定问题是否是内存泄露
3.  梳理问题分析思路
4.  动手分析解决
5.  总结

**1. 先说问题背景：**生产环境IIS站点，运行一段时间后，w3wp进程内存会涨到2G，同时内存不释放。

![23525-20181030105300560-1665910691.png][]

**2. 问题确认**

打开性能计数器，我们重点看一段时间内，IIS站点w3wp进程相关的性能计数器的变化：

![23525-20181030105606626-752990896.png][]

性能计数器中：有三个非常重要：

.NET CLR Memory/Gen 2 heap size  
.NET CLR Memory/Gen 1 heap size  
.NET CLR Memory/Gen 0 heap size  
托管堆上的对象有三代：  
第 0 代： 这是最年轻的代，其中包含短生存期对象。 短生存期对象的一个示例是临时变量。 垃圾回收最常发生在此代中。新分配的对象构成新一代的对象并且为隐式的第 0 代回收，除非它们是大对象，在这种情况下，它们将进入第 2 代回收中的大对象堆。大多数对象通过第 0 代中的垃圾回收进行回收，不会保留到下一代。  
第 1 代： 这一代包含短生存期对象并用作短生存期对象和长生存期对象之间的缓冲区。  
第 2 代： 这一代包含长生存期对象。 长生存期对象的一个示例是服务器应用程序中的一个包含在进程期间处于活动状态的静态数据的对象。当条件得到满足时，垃圾回收将在特定代上发生。 回收某个代意味着回收此代中的对象及其所有更年轻的代。 第 2 代垃圾回收也称为完整垃圾回收FullGC，因为它回收所有代上的所有对象（即，托管堆中的所有对象）。  
幸存和提升：垃圾回收中未回收的对象也称为幸存者，并会被提升到下一代。 在第 0 代垃圾回收中幸存的对象将被提升到第 1 代；在第 1 代垃圾回收中幸存的对象将被提升到第 2 代；而在第 2 代垃圾回收中幸存的对象将仍为第 2 代。  
通过代提升，看对象的存活时间！

Process/Private Bytes  
Process/Virtual Bytes  
.NET CLR Memory/\# Bytes in all Heaps : CLR内存托管堆的大小  
.NET CLR Memory/Large Object Heap Size: 大对象堆包含其大小为 85,000 个字节和更多字节的对象。

![23525-20181030105803105-1946605176.png][]

托管堆的内存大小增加的趋势和大对象堆增加的趋势重叠，可以初步推断，内存的增加和大对象有关系！

**3. 梳理问题分析思路**

连续、间隔抓两个或者三个Dump，每次抓Dump间隔半个小时，或者一个小时，主要看内存的增量。

![23525-20181030111043907-2024483911.png][]  
对比的看每个Dump中：

*  多核CPU情况下，分析每个GC托管堆的大小 !eeheap –gc
 *  查询内存中各类对象的总个数和总内存占用 !dumpheap –stat
 *  查询内存中大对象的个数和对象大小 !dumpheap –stat -mt -min 5000 -max 100000
 *  如果某一类或者几类对象的内存总占用很多，分析此类对象 !dumpheap –mt \*\*\*
 *  多次采样查看步骤4中对象的gcroot !gcroot addr
 *  打断gcroot中任何一个链条，释放对象引用

4. 动手分析

*  多核CPU情况下，分析每个GC托管堆的大小 !eeheap –gc

![23525-20181030111141989-107853247.png][]

*  查询内存中各类对象的总个数和总内存占用 !dumpheap –stat

![23525-20181030111240528-481895784.png][]

*  查询内存中大对象的个数和对象大小 !dumpheap –stat -mt -min 5000 -max 100000

![23525-20181030111321869-118802940.png][]

*  如果某一类或者几类对象的内存总占用很多，分析此类对象 !dumpheap –mt \*\*\* -stat

![23525-20181030111451576-1313267258.png][]

**大对象字符串分析，Session会话数据！同时Session会话中包含了权限数据！**

*  多次采样查看步骤4中对象的gcroot !gcroot addr

![23525-20181030111629181-1971682750.png][]

*  打断gcroot中任何一个链条，释放对象引用

**5. 总结**

总结一下，内存泄露问题分析，有固定的方法和指令，过程需要大家深入理解，同时熟悉代码非常重要，因为需要找出gcroot，分析出内存泄露的原因，再进行修改解决。

大的套路：

*  描述问题背景和现象
 *  确定问题是否是内存泄露
 *  梳理问题分析思路
 *  动手分析解决
 *  总结

详细的分析步骤：

欢迎大家补充。

周国庆

2018/10/30

转载于:https://www.cnblogs.com/tianqing/p/9875667.html

[23525-20181030105300560-1665910691.png]: /images/20211029/452a32a6679145bb8d7f1e3a4930aaa7.png
[23525-20181030105606626-752990896.png]: /images/20211029/3207604654b74e01b9037d61f58e701a.png
[23525-20181030105803105-1946605176.png]: /images/20211029/16023d3b5c2246e0a3de1378453196e7.png
[23525-20181030111043907-2024483911.png]: /images/20211029/8fee7f90cc404944b427bf5925cfd76a.png
[23525-20181030111141989-107853247.png]: /images/20211029/d4255afa988945f18bad0f62a68d7598.png
[23525-20181030111240528-481895784.png]: /images/20211029/01700aa146f642d5b46d32bbe2fd0eef.png
[23525-20181030111321869-118802940.png]: /images/20211029/7fc742b05cb944f388277dee8e9441c5.png
[23525-20181030111451576-1313267258.png]: /images/20211029/acd1934f56164dd3b4a0c74bad8ea107.png
[23525-20181030111629181-1971682750.png]: /images/20211029/884fbaf1295840fc91abaa54793a7219.png