调试.NET程序OutOfMemoryException

最新推荐文章于 2023-06-03 11:59:52 发布
最新推荐文章于 2023-06-03 11:59:52 发布
阅读量743 收藏 3
点赞数
文章标签： 操作系统

问题简介

Out of memory异常是如何产生的

总的来说OutOfMemoryException会在两种情况下发生，

  1. 进程虚拟内存空间耗尽
  2. 系统物理内存耗尽

第二种情况我们可以参照系统进程管理器中性能选项卡，如果其中committed数值接近了limit,那说明第二种情况发生了。

不过大多数时候OutOfMemoryException发生是因为第一种原因，接下来我们将重点研究虚拟地址空间耗尽的问题。

无论机器插了多少内存条，32位操作系统可以寻址4GB的地址空间，如果系统没有打开3GB开关的话，其中2GB分配给操作系统内核，另外2GB分配给用户程序。内核的2GB空间被所有的进程，操作系统所共享。但用户模式的那2GB空间为每个进程独享。

我们来简单描述一下CLR内存分配的方式，当应用程序需要分配内存空间的时候，CLR会分配一段连续空间64MB给应用程序使用，如果应用程序需要分配的内存大于85000byte，那么这部分内存会在大对象堆中分配，如果大对象堆中没有这么大的连续内存空间，则为大对象堆分配新的一段16MB。如果一直这样分配下去的话，总会达到一个上限无法满足连续空间的分配请求，因为我们只有2GB的用户模式内存空间。这样outof memory异常就会发生了。当然我们没有讨论垃圾回收器会不停的回收内存，整理压缩空间。

主要两大原因会使进程虚拟内存耗尽，

  1. 程序分配的速度大于内存回收速度
  2. 虚拟内存地址空间太多碎片，减少了连续空间分配的可能性

通常情况下，当32位应用程序虚拟内存使用了800M以上的时候，发生out of memory的几率会大大增加，因为内存碎片难以避免，连续内存空间可能所剩不多，这也是为什么会发现在内存使用率增高的情况下性能会逐步下降，因为垃圾回收的几率也在提高。

问题重现

接下来我们来看一个out ofmemory的例子。

using System;
using System.Collections.ObjectModel;

namespace DemoOOM
{
    class Program
    {
        Collection<byte[]> roots = new Collection<byte[]>();
        static void Main(string[] args)
        {
            try
            {
                Program p = new Program();
                p.AllocateSmallObjects();
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex);
            }
            Console.Read();
        }

        void AllocateSmallObjects()
        {
            byte[] smallObject;
            int i = 1;
            while (true)
            {
                smallObject = new byte[80*1024];
                Console.WriteLine("allocate {0} 80K object", i);
                roots.Add(smallObject);
                i++;
            }
        }
    }
}


22809* 80KB = 1781MB = 1.73GB，可以看到即使我们连续分配内存，碎片很少的情况下依然只能使用1.73左右的内存空间，进程需要空间分配给加载的dll文件，大对象堆，还有进程默认堆，线程堆栈，所有我们只能在接近2GB的时候发生OOM。

调试方法

接下来我们介绍一个OOM收集数据的基本方法

配置性能计数器(performance counter)

新建一个性能计数的日志收集，加入以下性能技术

•Process/PrivateBytes

•Process/VirtualBytes

•.NET CLRMemory/All counters

•.NET CLRLoading/All counters

更改注册表

添加如下注册表键值，使得在OOM产生的时候系统会让程序马上抛出一个breakpointexception，导致程序崩溃以便我们抓取dump。

.NET framework 1.1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\
DWord: GCFailFastOnOOM
Value: 2

.NET framework 2.0及以上

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\GCBreakOnOOM

Dword: GCBreakOnOOM

Value: 2

配置DebugDiag

  1. 安装 DebugDiag然后打开
  2. 点击添加规则，选择crash继续
  3. 选择All IIS Processes然后选择Advanced Exception Configuration
  4. 选择Add Exception - Breakpoint Exception
  5. ActionType选择Full UserDump
  6. 保存之后关闭
  7. 继续添加Advanced Breakpoint Configuration
  8. AddBreakpoint之后输入KERNEL32!ExitProcess
  9. ActionType选择Full UserDump
  10. 保存后下一步继续

还有关键的一步，切换到Processes选项卡，右键单击w3wp进程选择Monitor For Leaks，这是为了在进程中注入一个LeakTrace的Dll，有了它我们可以追踪非托管内存的分配情况，监测泄露。

问题发生之后memorydump会自动生成在debugdiag配置好的目录下面，同时停掉性能计数器。数据收集完毕。

如何去查看OOM的dump

我们已经知道发生了OOM异常，通过加载psscor2调试扩展，调用!dumpallexceptions来查看发生的所有的异常信息，发现OutOfMemoryException数量为2。注意这里有三个异常会一直列在这里，如果没有发生过该异常，他们的数量为1。

  • System.ExecutionEngineException
  • System.StackOverflowException
  • System.OutOfMemoryException

原因是系统为了防止在这三种情况下没有机会创建相应的异常，所以先在堆里面创建好了三个备用。

0:000>!dae
Going todump the .NET Exceptions found in the heap.
Number ofexceptions of this type: 1
ExceptionMethodTable: 7856106c
Exceptionobject: 027510b4
Exceptiontype: System.ExecutionEngineException
Message:<none>
InnerException:<none>
StackTrace(generated):
<none>
StackTraceString:<none>
HResult:80131506
-----------------
Number ofexceptions of this type: 1
ExceptionMethodTable: 78560fdc
Exceptionobject: 0275106c
Exceptiontype: System.StackOverflowException
Message:<none>
InnerException:<none>
StackTrace(generated):
<none>
StackTraceString:<none>
HResult:800703e9
-----------------
Number of exceptions ofthistype: 2
ExceptionMethodTable: 78560f4c
Exceptionobject: 7e742848
Exception type:System.OutOfMemoryException
Message:<none>
InnerException:<none>
StackTrace(generated):
SP IP Function
002FF0B8 004F00F8DemoOOM.Program.AllocateSmallObjects()
002FF0D0 004F0092DemoOOM.Program.Main(System.String[])
StackTraceString:<none>
HResult:8007000e
-----------------

通过address命令来看内存的使用情况，可以看到

１．程序几乎用光了2G地址空间

２．内存中最大的free region只有15.3M，满足不了64M的分配需求。

0:000>!address -summary
--- UsageSummary ---------------- RgnCount ----------- Total Size -------- %ofBusy%ofTotal
<unknown> 270 76475000 ( 1.848 Gb) 97.52% 92.41%
Free 67 6b54000 ( 107.328 Mb) 5.24%
Image 204 29e0000 ( 41.875 Mb) 2.16% 2.04%
Heap 17 300000 ( 3.000 Mb) 0.15% 0.15%
Stack 17 300000 ( 3.000 Mb) 0.15% 0.15%
Other 10 43000 ( 268.000 kb) 0.01% 0.01%
TEB 3 3000 ( 12.000 kb) 0.00% 0.00%
PEB 1 1000 ( 4.000 kb) 0.00% 0.00%


--- TypeSummary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy%ofTotal
MEM_PRIVATE 265 74c48000 ( 1.824 Gb) 96.27% 91.23%
MEM_IMAGE 231 2c2d000 ( 44.176 Mb) 2.28% 2.16%
MEM_MAPPED 26 1c27000 ( 28.152 Mb) 1.45% 1.37%


--- StateSummary ---------------- RgnCount ----------- Total Size -------- %ofBusy%ofTotal
MEM_COMMIT 385 754f5000 ( 1.833 Gb) 96.72% 91.65%
MEM_FREE 67 6b54000 ( 107.328 Mb) 5.24%
MEM_RESERVE 137 3fa7000 ( 63.652 Mb) 3.28% 3.11%


---Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy%ofTotal
PAGE_READWRITE 203 7233e000 ( 1.784 Gb) 94.16% 89.22%
PAGE_EXECUTE_READ 34 1c78000 ( 28.469 Mb) 1.47% 1.39%
PAGE_READONLY 92 136b000 ( 19.418 Mb) 1.00% 0.95%
PAGE_WRITECOPY 29 191000 ( 1.566 Mb) 0.08% 0.08%
PAGE_EXECUTE_WRITECOPY 2 1a000 ( 104.000 kb) 0.01% 0.00%
PAGE_EXECUTE_READWRITE 18 19000 ( 100.000 kb) 0.01% 0.00%
PAGE_READWRITE|PAGE_GUARD 7 10000 ( 64.000 kb) 0.00% 0.00%


---Largest Region by Usage ----------- Base Address -------- Region Size----------
<unknown> 42ab0000 2350000 ( 35.313 Mb)
Free 72f7b000 f55000 ( 15.332 Mb)
Image 7848f000 8f4000 ( 8.953 Mb)
Heap 11c9000 d7000 (860.000 kb)
Stack c01000 fb000 (1004.000kb)
Other 7efa0000 33000 (204.000 kb)
TEB 7efd7000 1000 ( 4.000 kb)
PEB 7efde000 1000 ( 4.000 kb)


通过dumpheap命令来查看托管堆中对象，发现占用内存最多是22819个byte数组。总大小为1.78G左右。在实际的分析中，我们要关注使用内存最多的对象，同时也要格外关注占用内存最多的属于我们自己定义的命名空间的对象。

0:000>!dumpheap -stat
Using ourcache to search the heap.
...
0x7856337c 16 896 System.Collections.Hashtable
0x78561ea8 63 1,260 System.RuntimeType
0x7854cb0c 65 1,560System.Security.Policy.StrongNameMembershipCondition
0x78563478 16 2,304System.Collections.Hashtable+bucket[]
0x78561958 34 6,068 System.Char[]
0x7854c8b8 232 6,496 System.Security.SecurityElement
0x78562d58 278 6,672 System.Collections.ArrayList
0x785344f8 338 34,232 System.Object[]
0x78560d28 547 47,940 System.String
0x0034efc8 30 131,060 Free
0x78544ee8 2 131,104 System.Byte[][]
0x78563798 22,819 1,868,788,720 System.Byte[]
Total24,752 objects, Total size: 1,869,168,208

通过dumpheap加-mt参数来将所有的byte数组列出，发现byte数组分配非常的齐整，都是81,932，通过加-gen 2参数发现这些数组全部都在第二代。

为什么这么多byte数组？这是我们为了演示，但是实际中的dump我们肯定要认真思考他们来自哪里。

为什么全在第二代？接下来继续。

0:000>!dumpheap -mt 0x78563798
Using ourcache to search the heap.
Address MT Size Gen
0x0275427c0x78563798 12 2 System.Byte[]
...
0x027b92100x78563798 81,932 2 System.Byte[]
0x027cd21c0x78563798 81,932 2 System.Byte[]
0x027e12280x78563798 81,932 2 System.Byte[]
0x027f52340x78563798 81,932 2 System.Byte[]
0x028092400x78563798 81,932 2 System.Byte[]
0x0281d24c0x78563798 81,932 2 System.Byte[]
0x028312580x78563798 81,932 2 System.Byte[]
…
0:000>!dumpheap -mt 0x78563798 -gen2
Using ourcache to search the heap.
Address MT Size Gen
0x0275427c0x78563798 12 2 System.Byte[]
...
0x0277d1ec0x78563798 81,932 2 System.Byte[]
0x027911f80x78563798 81,932 2 System.Byte[]
0x027a52040x78563798 81,932 2 System.Byte[]
0x027b92100x78563798 81,932 2 System.Byte[]
0x027cd21c0x78563798 81,932 2 System.Byte[]
0x027e12280x78563798 81,932 2 System.Byte[]
0x027f52340x78563798 81,932 2 System.Byte[]
0x028092400x78563798 81,932 2 System.Byte[]

通过GCRoot命令来查看对象的根。可以看到对象最终被一个Collection<Byte[]>所引用。

0:004>!gcroot 0x027911f8
Note:Roots found on stacks may be false positives. Run "!help gcroot" for
moreinfo.
ScanThread 0 OSThread 169c
ESP:3bef1c:Root: 02a6797c(System.Collections.ObjectModel.Collection`1[[System.Byte[],mscorlib]])->
02a6798c(System.Collections.Generic.List`1[[System.Byte[],mscorlib]])->
2df0d1a4(System.Byte[][])->
27911f8(System.Byte[])
ESP:3bef30:Root: 02a6797c(System.Collections.ObjectModel.Collection`1[[System.Byte[],mscorlib]])->
02a6798c(System.Collections.Generic.List`1[[System.Byte[],mscorlib]])->
2df0d1a4(System.Byte[][])->
27911f8(System.Byte[])
ESP:3befc8:Root: 02a67970(DemoOOM.Program)->
02a6797c(System.Collections.ObjectModel.Collection`1[[System.Byte[],mscorlib]])->
02a6798c(System.Collections.Generic.List`1[[System.Byte[],mscorlib]])->
2df0d1a4(System.Byte[][])->
27911f8(System.Byte[])
ScanThread 2 OSThread 2cc8

通过objsize命令来看看这个根的大小？接近1.8G全被他占了。

0:000>!objsize 02a6797c
sizeof(0281797c)= 1,868,918,116 ( 0x6f656d64) bytes(System.Collections.ObjectModel.Collection`1[[System.Byte[], mscorlib]])

这个例子只是一个理想情况下的演示实例，现实世界中的问题不可能这么显而易见，最主要的还是要找到内存使用量最大的数据来自于哪里，存在是否合理。

内存使用量大的对象可以从堆得使用里观察(!dumpheap 带不同的参数)

这些对象来自于哪里可以根据

  1. 对象实例本身的数据(!do命令查看对象属性)
  2. 对象的根的路径(!gcroot查看对象根路径)

找到了这些对象并弄清楚他们来自何处，接下来就是要根据逻辑来判断这些对象的存在是否合理了，比如

  1. 分配这些对象的必要性
  2. 对象是否没有及时释放

最终我们把内存中不合理的存在都去除，如果还是抛OutOfMemoryException，那就考虑将程序移植到64位的系统上吧。

参考文档

http://support.microsoft.com/?id=248345

http://support.microsoft.com/?id=820745

iteye_3606
关注
调试.NET Web应用程序High Memory - Part 2
Web Debug
09-23 2316
在第二部分我们主要介绍针对各种内存问题的主要调试方式。在开始之前我还是推荐一个常规的调试步骤。   Part1我们提到过debugdiag工具以及如何通过其内建的rule来分析dump。   收集dump通过DebugDiag选择Managed Memory Analysis规则来做一遍分析根据DebugDiag分析报告通过windbg打开dump查看更多信息   大数据量da
ASP.NET中的OutOfMemoryException
weixin_34245169的博客
05-07 751
在博客园看到了一位园友写的文章《如何处理OutOfMemoryException异常？》，于是想和大家交流一下ASP.NET中出现OutOfMemoryException的问题。 实际上，在ASP.NET Web服务器上，ASP.NET所能够用到的内存，通常不会等同于所有的内存数量。在machine.config配置文件中， 配置节&lt;processModel&gt;中有一个属性“...
Net 内存溢出（System.OutOfMemoryException）的常见情况和处理方式总结
09-23
在什么情况下会出现OutOfMemonryException呢? 在我们试图新建一个对象时,而垃圾收集器又找不到任何可用内存时被抛出,这种情况下我们是可以捕获该 异常的; 另一种情况是,CLR需要内存时,而却系统却不能提供,也会抛出该异常. 但此时,我们的应用程序是不能捕获该错误的.
[原]发现并解决ASP.NET内存耗尽(OOM),让服务器"永不重启"
akulakk's memory stack
04-27 1262
对于大型程序,完全依赖GC是不现实的,对于高负载服务器,往往我们80%的堆都由自己的析构函数接管,并辅助以自行设计的bufferpool接管堆释放工作以达到HEAP可控的目的,减少CPU突发性负荷(CPU尖峰).虽然不像C那样可以控制的那么完全,但是多多少少对OOM的发生起到抑制作用,深入下去可以完全避免OOM......好了IF性能和内存开销没什么追求的 THEN 就不必看了,,,,ELSE
内存不足(OutOfMemory)的调试分析
ABlog
08-20 2万+
32位操作系统的寻址空间是4G，其中有2G被操作系统占用，也就是说留给用户进程的内存只有2G（其中还要扣除程序加载时映像占用的部分空间，一般只有1.6G~1.8G左右可以使用）。 如果进程运行中需要申请内存，而操作系统无法为其分配内存空间，则会产生内存不足的异常，在.net中为
.NET陷阱之五：奇怪的OutOfMemoryException——大对象堆引起的问题与对策
iNeuOS工业互联网
08-20 1656
我们在开发过程中曾经遇到过一个奇怪的问题：当软件加载了很多比较大规模的数据后，会偶尔出现OutOfMemoryException异常，但通过内存检查工具却发现还有很多可用内存。于是我们怀疑是可用内存总量充足，但却没有足够的连续内存了——也就是说存在很多未分配的内存空隙。但不是说.NET运行时的垃圾收集器会压缩使用中的内存，从而使已经释放的内存空隙连成一片吗？于是我深入研究了一下垃圾回收相关的内容，最终明确的了问题所在——大对象堆（LOH）的使用。如果你也遇到过类似的问题或者对相关的细节有兴趣的话，就继续读读
.Net 内存溢出（System.OutOfMemoryException）的常见情况和处理方式总结
热门推荐
霍力强的专栏
05-23 4万+
在什么情况下会出现OutOfMemonryException呢? 在我们试图新建一个对象时,而垃圾收集器又找不到任何可用内存时被抛出,这种情况下我们是可以捕获该异常的; 另一种情况是,CLR需要内存时,而却系统却不能提供,也会抛出该异常. 但此时,我们的应用程序是不能捕获该错误的.内存溢出(OutOfMemoryException）的调试分析32位操作系统的寻址空间是4G，其中有2G被操作系统
.NET调试案例：探索Windbg与内存问题
"本文主要介绍了如何使用Windbg调试.NET程序中的内存问题，特别是针对System.OutOfMemoryException的排查。通过压力测试BuggyBits站点来模拟内存泄漏情况，并详细阐述了设置性能计数器日志的过程，以便分析内存使用...
捕捉.net无法捕捉的错误
04-03
这类错误通常涉及到系统级的问题，如内存溢出、线程中断或者操作系统的限制，这些错误可能导致应用程序崩溃而没有提供任何有用的调试信息。 在.NET框架中，开发者通常使用try-catch语句来捕获和处理可能出现的异常...
.NET-第5部分.ppt
11-19
通过这种方式，程序员可以对不同类型的异常进行差异化处理，提供错误信息，帮助调试，并在适当的情况下尝试恢复程序的正常运行。 另一方面，类型管理在.NET框架中主要涉及到自动内存管理，这是通过垃圾收集...
分析性能瓶颈 — 调试OutOfMemoryException
weixin_34244102的博客
07-03 306
在前面的文章里面，执行性能测试—起步里，讲了执行性能测试的基本步骤，而且在前面的例子里面，通过一个2M多的文本文件，对比了冒泡排序和快速排序的性能之间的差别。但是当我使用一个700M大小的文本文件进行测试的时候—因为我需要了解在极端情况下两种排序方法的差别。原定是2G的文本文件，但是无论快排还是冒泡排序都要求被排序的数据完全存在于内存当中，对于32位机，2G的数据是一个上限，因为操作系统的内核代码...
使用Perfmon.exe调试分析内存不足(OutOfMemory)
weixin_30905133的博客
04-04 519
32位操作系统的寻址空间是4G，其中有2G被操作系统占用，也就是说留给用户进程的内存只有2G（其中还要扣除程序加载时映像占用的部分空间，一般只有1.6G~1.8G左右可以使用）。 如果进程运行中需要申请内存，而操作系统无法为其分配内存空间，则会产生内存不足的异常，在.net中为System.OutOfMemoryException（The exception that is thrown whe...
ASP.NET 中关于 System.OutOfMemoryException 的问题与解决方法
netbug2009的专栏
12-10 6427
<br />之所以发生System.OutOfMemoryException这个问题，是因为多处理器（或多核心）计算机上的 .NET CLR 的 Garbage Collection (GC) 机制默认是使用 Server Mode (服务器模式) 在运行的，换句话说，就是「每一颗 CPU 都会有独立的 GC 内存空间(堆栈, Heap)」，所以如果你的 GC 内存空间用掉了 500MB 且你有 4 颗 CPU 的话，就等于耗费了 2GB 的内存，进而发生 System.OutOfMemoryExcepti
遭遇OutOfMemoryError
老唐 的专栏
01-18 3万+
这几天，网店系统基础架构进行了一次大的升级，升级之后例行的进行了压力测试，以前几次大的项目发布压力测试都没有任何问题，没想到这次出事故啦，而且是内存泄露？系统运行环境：硬件：Intel(R) Xeon(R) CPU 2.0G、4G RAM、Linux 2.6.9-42.ELsmp #1 SMP 软件：jboss-4.0.5.GA [Java HotSpot(TM) Server VM (bui
.Net的Outofmemory异常及大内存使用
Risk的专栏
07-06 2361
        从去年起我们的服务器偶尔会抛出OutOfMemoryException，即没有足够的内存继续执行程序时引发的异常。服务器内存加到4G也仍会出现该问题。软件是UO的第三方模拟器。事实上，从任务管理器里，可以看到软件占用了约1G左右的内存，当然因为GC的缘故，实际软件使用的内存在600M左右。为避免超过1G多内存的占用，并抛出Outofmemory异常，设定在内存占用到一定值时进行强制
记录一次虚拟机报 outOfMemory (OOM)排查问题，和解决问题的过程
ggg6568的博客
06-03 1442
解决内存溢出问题，OOM解决示例
一次性能调优记录：压测报错out of memory内存溢出【杭州多测师_王sir】【杭州多测师】...
多测师_王sir的博客
12-17 1199
一次性能调优记录：压测报错outofmemory内存溢出1、首先这是一段压测的报错日志截图 2、服务器的配置还不错，执行机全64核以上，运存256g以上，服务器80核，512g，所有机器线程数设置655360 3、刚开始以为是jmeter和Tomcat服务器的JVM里面的堆内存，新生代和老年代的参数设置太小了 4、然后进行的设置，设置之后发现还是有问题，发现启动jmeter的时候，配置还...
.net system.outofmemoryexception
06-06
当.NET应用程序中出现System.OutOfMemoryException，意味着该应用程序已经用完了所有可用的内存，无法再分配更多的内存空间，从而导致出现错误。 这种错误通常与应用程序的内存管理有关。在编写.NET应用程序时，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值