发现内存泄漏 [英] Finding memory leak

问题描述

我有一个Web应用程序，我使用很多不同的第三方组件，CMS，当然还有我的代码。出于某种原因，我的内存异常。

脚本引发异常：内存不足

我试图找出发生了什么。这就是我发现的：

• 我用50个线程运行测试来调用我的web应用程序的15个页面。记忆似乎很好。 IIS进程只使用400 MB的RAM




• 我在web.config中添加了一个空格，突然间我的IIS进程开始增长到不止一个GB在30分钟内完成。
  Visual Studio无法获取我的内存快照，因为它太大了（真的吗？！）所以我安装了ANTS内存分析器，但它说我的应用程序只使用了大约300 MB

IIS进程占用1 GB
pY.png

我在几分钟后停止了测试，但内存尚未释放。

（ANTS探测器停止工作，所以我重新启动它）

它似乎不是应用程序使用100-200MB内存特别是我正在为我的控制器使用输出缓存。我不明白为什么IIS消耗的内存一直在增长，出现了什么问题

更新

我的应用程序已经自动重启，W3WP崩溃导致IIS释放内存而我的压力没有运行一段时间：

应用程序：w3wp.exe
框架版本：v4.0.30319
描述：由于.NET运行时在IP 5A3A86F1（5A0F0000）处出现内部错误而导致进程终止，退出代码为80131506。

和

错误的应用程序名称：w3wp.exe ，版本：10.0.15063.0，时间戳：0xacce422f
错误模块名称：clr.dll，版本：4.7.2098.0，时间戳：0x59028d36
异常代码：0xc0000005
错误偏移量：0x002b86f1
错误进程id：0x50a4
错误的应用程序启动时间：0x01d2ee688f323893
错误的应用程序路径：C：\ WINDOWS \ SysWOW6 4 \inetsrv\w3wp.exe
错误模块路径：C：\ Windows \ Microsoftoft.NET\Framework\v4.0.30319\clr.dll
报告标识：4362ddc5-f8d7 -4441-8916-3830f9268b3a
错误包裹全名：
错误包裹相关申请ID：

< a href =https://i.stack.imgur.com/UvZCz.png =noreferrer>

更新2

我运行DebugDiag并且我有压力测试了网站，直到它消耗了大约3.5 GB的RAM。

Chakra是微软的图书馆。

所以现在我有两个问题。

1. ChakraCore是否有泄漏或是否正在使用/分配？如何定义哪个库？

2-它说27,000个分配。这是否意味着内存中仍有27,000个或者其中一些可能被分配然后处理？

3-它仍然没有告诉我任何有关其余内容的信息占用3GB的RAM。它总共只有600 MB（私有+虚拟）。

解决方案

在你的分析中，我看到.net分析是做得不对。您是否在捕获内存转储的同一台机器上进行分析？

要使debugdiag正常工作，您必须具有相同的功能分析机上安装的
.net框架（应用程序）的版本
。

请不要像

开始压力测试

检查内存使用情况，一旦到达说1 GB，捕获挂起转储

• 右键单击w3wp.exe进程


• 选择Create Full选项内存转储
  

捕获另一个2 GB转储和一个转储3.5 GB

您应该在文件夹C中捕获转储：\ ProgramFiles \DebugDiag \ Logs \ Misc \

右键单击在转储文件上，选择分析.NET内存问题

现在比较分析每个转储文件（1 GB，2 GB，3.5 GB），
应该告诉你哪些.NET对象正在增加并且没有收到
垃圾。

在内存分析中，您应该看到 CLR信息**** ,. NET GC堆信息，大多数内存消耗.NET对象等如下。如果你的.net符号被debugdiag分析正确识别，就会出现这种情况。

  CLR信息
 CLR version = 4.6.1648.0 
 Microsoft.Diagnostics.Runtime version = 0.9.2.0 
 .NET GC堆信息
 GC堆数量：4 
堆大小0x4001ce8（67,116,264）
堆大小0x3d5cca0 （64343200）
堆大小0x3f8b0d0（66629840）
堆大小0x3ccb0d0（63746256）
 GC堆大小249.71 MB的
共提交大小249 MB 
共计预留尺寸17158 MB 
 
 40大多数内存消耗.NET对象类型
 
 System.Char [] 193.01 MBytes（12450个对象）
免费45.21 MBytes（4760个对象）
 System.String 1.56 MBytes（18072个对象）
 ==============剪掉===================== == 
  

DebugDaig自动分析应该给出以下

1. **错误或警告** - 密切注意debu显示的警告或错误gdiag分析在报告的顶部。


2. .NET GC堆信息 - 总提交大小 - 这大致相当于.net内存使用情况。


3. 大多数消耗大量内存的.NET对象类型 - 这可用于比较连续转储中的内存增加。这将告诉你哪些对象导致了问题。有些时候你根本就没有使用过的某些对象可能来自某些第三方库。或者你会看到你自己创建的对象


4. Finalizer队列中的热门对象 - 如果您的终结器可能被阻止，这将为您提供任何线索。对象。讨论类似的问题此处和这里


5. 大对象堆上的对象 - 这会导致内存碎片和大对象堆容器对象的大小超过85K。


6. 缓存，数据表，应用程序域，动态程序集等的大小。

请注意，有时debugdiag自动分析无法弄清楚根本原因和需要使用windbg手动分析。 DebugDiag分析，请参考视频。

希望这会有所帮助！

I have a web application that I wrote using a lot of different 3rd party components, a CMS and of course my code. For some reason I get out of memory exception.

Script threw an exception: Out of memory

I tried to find out what is going on. This is what I've found:

• I ran the test with 50 threads to call 15 pages of my web-application. Memory seems fine. The IIS process is using only 400 MB of RAM

• I've added a space in web.config and suddenly my IIS process started to grow to more than a GB in 30 minutes. Visual studio could not take snapshot of my memory since it is too big (really?!) So I've installed ANTS memory profiler but it says that my application is using only around 300 MB

IIS process takes 1 GB pY.png

I stopped the test after some minutes but the memory has not released.

(ANTS profiler stopped working so I've restarted it)

It doesn't seem like the application is using 100-200MB memory specially that I am using output caching for my controllers. What I don't understand is why memory consumed by IIS is growing all the time and what is wrong

Update

My application has been restarted automatically with a crash in W3WP causing IIS to release the memory while my stress was not running for a while:

Application: w3wp.exe Framework Version: v4.0.30319 Description: The process was terminated due to an internal error in the .NET Runtime at IP 5A3A86F1 (5A0F0000) with exit code 80131506.

and

Faulting application name: w3wp.exe, version: 10.0.15063.0, time stamp: 0xacce422f Faulting module name: clr.dll, version: 4.7.2098.0, time stamp: 0x59028d36 Exception code: 0xc0000005 Fault offset: 0x002b86f1 Faulting process id: 0x50a4 Faulting application start time: 0x01d2ee688f323893 Faulting application path: C:\WINDOWS\SysWOW64\inetsrv\w3wp.exe Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Report Id: 4362ddc5-f8d7-4441-8916-3830f9268b3a Faulting package full name: Faulting package-relative application ID:

Update 2

I ran DebugDiag and I've stress tested the site until it consumed around 3.5 GB of my RAM.

And Chakra is a Microsoft's library.

So now I have 2 questions.

1. Is it the ChakraCore that has leak or is it the one that is using/allocating it? How to define which library?

2- It says 27,000 allocations. Does it mean that there are still 27,000 in the memory or some of them might be allocated and then disposed?

3- It still doesn't tell me anything about the rest of 3GB of consumed RAM. it i only 600 MB in total (private+virtual).

解决方案

In your analysis, I see that the .net analysis is not done correctly. Are you doing analysis in the same machine where you have captured the memory dump ?

For debugdiag to work correctly, you have to have the same version of .net framework (of the application) installed on the analyzing machine as well.

Also Please do not do native memory leak dump like this ,unless it is not figured out unmanaged leak.From the analysis of yours, it looks like this is managed leak.

When you changed the web.config file,it causes an Application domain unload and reload

Let's do step by step

1. Using DebugDiag(capture consecutive hang dumps)
   • Launch DebugDiag Collection and Go to the Processes tab
   • Start your stress test
   • check the memory usage and once it reaches say 1 GB,capture a hang dump
     • right click on the w3wp.exe process
     • choose the option Create Full Memory dump
   • Capture another dump at 2 GB and one at 3.5 GB
   • You should have dumps captured in the folder C:\ProgramFiles\DebugDiag\Logs\Misc\
   • Right click on the dump file and choose the option Analyse .NET Memory Issue

Now compare the analysis of each dump file(1 GB,2 GB, 3.5 GB), it should tell you which .NET objects are increasing and not getting garbage collected.

In the memory analysis, you should see CLR Information****,.NET GC Heap Information ,Most memory Consuming .NET Objects etc like below. This will come if your .net symbols are correctly identified by debugdiag analysis

CLR Information
 CLR version = 4.6.1648.0
 Microsoft.Diagnostics.Runtime version = 0.9.2.0
.NET GC Heap Information
Number of GC Heaps: 4 
Heap Size 0x4001ce8 (67,116,264) 
Heap Size 0x3d5cca0 (64,343,200) 
Heap Size 0x3f8b0d0 (66,629,840) 
Heap Size 0x3ccb0d0 (63,746,256) 
GC Heap Size 249.71 MBytes  
Total Commit Size  249 MB 
Total Reserved Size    17158 MB 

40 most memory consuming .NET object types

System.Char[]   193.01 MBytes    (12450 objects )
Free      45.21 MBytes    (4760 objects )
System.String      1.56 MBytes    (18072 objects ) 
==============trimmed out =======================

DebugDaig Automated analysis should give following

1. **Errors or Warnings **- pay close attention to warning or errors displayed by debugdiag analysis on the top of the report.
2. .NET GC Heap Information - Total Commit Size - This will roughly equal to your .net memory usage.
3. 40 most memory consuming .NET object types -This can be used to compare against your memory increase in consecutive dumps. This will tell you which objects are causing issue.Sometimes some objects you are not using at all will be coming and might be coming from some third party library.Or you will see objects which you yourself have created
4. Top Objects in the Finalizer queue - This will give you any clue if your finalizer may be blocked .Objects.Some similar issues are discussed here and here
5. Objects on the Large Object Heap - This causes memory fragmentation and large object heap contaisn objects which are more than 85K in size.
6. Size of Cache, Datatables,Application domains,Dynamic assemblies etc. It's not a good idea to have large number of application domain in one process

Please note that sometimes the debugdiag automated analysis cannot figure out the root cause and needs manual analysis using windbg. DebugDiag analysis,please refer this video.

Hope this helps!

这篇关于发现内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！