发现内存泄漏

Ash*_*ous 7 c# iis asp.net-mvc memory-leaks memory-management

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

脚本引发了异常:内存不足

我试图找出发生了什么.这就是我发现的:

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

  • 我在web.config中添加了一个空格,突然我的IIS进程在30分钟内开始增长到超过GB.Visual Studio无法拍摄我的内存快照,因为它太大了(真的吗?!)所以我安装了ANTS内存分析器,但它说我的应用程序只使用了大约300 MBANTS只有300 MB

IIS进程需要1 GB [1]:https://i.stack.imgur.com/Ig8pY.png

几分钟后我停止了测试,但内存没有释放.

(ANTS探测器停止工作,所以我重新启动它) 发布后422MB IIS 1.2GB 摘要 4MB的字符串

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

更新

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

应用程序:w3wp.exe Framework版本: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\SysWOW64\inetsrv\w3wp.exe错误模块路径:C:\ Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll报告ID:4362ddc5-f8d7- 4441-8916-3830f9268b3a错误包全名:错误包相关申请ID:

在此输入图像描述

更新2

我运行DebugDiag并且我已经对网站进行了压力测试,直到它消耗了大约3.5 GB的RAM.

在此输入图像描述

Chakra是微软的图书馆.

在此输入图像描述 在此输入图像描述

所以现在我有2个问题.

  1. ChakraCore是泄漏还是正在使用/分配它?如何定义哪个库?

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

3-它还没有告诉我任何关于3GB消耗RAM的剩余部分.它我总共只有600 MB(私有+虚拟).

Roh*_*ith 5

在您的分析中,我发现 .net 分析未正确完成。您是否在捕获内存转储的同一台机器上进行分析?

为了使 debugdiag 正常工作,您还必须在分析计算机上安装相同版本的 .net Framework(应用程序)。

另外请不要像这样进行本机内存泄漏转储,除非没有弄清楚非托管泄漏。从您的分析来看,这看起来像是托管泄漏。

当您更改 web.config 文件时,它会导致应用程序域卸载并重新加载

让我们一步一步来做

  1. 使用 DebugDiag(捕获连续的挂起转储)
    • 启动DebugDiag Collection并转到“进程”选项卡 调试诊断进程选项卡
    • 开始你的压力测试
    • 检查内存使用情况,一旦达到 1 GB,捕获挂起转储
      • 右键单击 w3wp.exe 进程
      • 选择选项创建完整内存转储 捕获完整内存挂起转储
    • 捕获另一个 2 GB 的转储和一个 3.5 GB 的转储
    • 您应该在文件夹 C:\ProgramFiles\DebugDiag\Logs\Misc\ 中捕获转储
    • 右键单击转储文件并选择选项“分析 .NET 内存问题” 分析.net内存问题

现在比较每个转储文件(1 GB、2 GB、3.5 GB)的分析,它应该告诉您哪些 .NET 对象正在增加并且没有被垃圾收集。

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

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 =======================
Run Code Online (Sandbox Code Playgroud)

DebugDaig 自动分析应给出以下结果

  1. **错误或警告 **- 密切注意报告顶部的 debugdiag 分析显示的警告或错误。
  2. .NET GC 堆信息-总提交大小 - 这将大致等于您的 .net 内存使用量。
  3. 40 个最消耗内存的 .NET 对象类型- 这可用于与连续转储中的内存增加进行比较。这将告诉您哪些对象导致问题。有时,您根本不使用的一些对象将会出现,并且可能来自某些第三方库。或者您会看到您自己创建的对象
  4. 终结器队列中的顶级对象- 如果终结器可能被阻止,这将为您提供任何线索。对象。此处此处 讨论了一些类似的问题
  5. 大对象堆上的对象- 这会导致内存碎片,并且大对象堆包含大小超过 85K 的对象。
  6. 缓存、数据表、应用程序域、动态程序集等的大小。在一个进程中拥有大量应用程序域并不是一个好主意

请注意,有时debugdiag自动分析无法找出根本原因,需要使用windbg手动分析。DebugDiag分析,请参考此视频

希望这可以帮助!