三个关键命令找出ASP.NET程序内存分片的原因

http://www.cnblogs.com/lixiong/archive/2007/10/26/938430.html

最近一位朋友的ASP.NET程序怀疑有内存泄露问题。几个简单的页面,起来运行几分钟后,虚拟内存就到600多MB。从性能监视上看,private bytes只有200多MB。

这样的问题从经验上来说,十有八九都是内存碎片了。ASP.NET程序发生内存碎片的原因比较多,我常见的有:


1. Web.config中的debug=true,导致batch compilation=false,使得每一个ASPX页面都生成一个临时assembly。当页面比较多的时候,大量的assembly导致内存泄露。
2. 程序中误用了XmlSerializer。频繁的XML序列化导致大量的动态assembly
3. 程序中有大量的blocking IO操作,而且IO buffer没有及时释放。比如程序中有大量的Web Service调用,但是对方web service返回比较慢,使得调用程序中用来接收web service结果的小块buffer大量堆积,导致内存泄露

下面是我拿到dump后的分析步骤。对于managed程序,找出问题的大致线索还是挺简单的。


(随便无耻地推销下,《Windows高效排错》书中对这样的问题有更多的讨论。包括更多的案例和命令解释。该书最初的PDF草稿在http://www.cnblogs.com/lixiong/archive/2006/08/16/475520.html。如果有朋友从这个PDF中找到过排错的灵感,麻烦也帮忙无耻推销下。)


首先是看看CLR的版本了。这个直接看mscorwks文件或者mscorsrv文件。如果文件版本比较低,后面的就没必要仔细看了,升级CLR补丁后再说。


0:000> lmvm mscorwks
start    end        module name
79e70000 7a3d6000   mscorwks   (deferred)            
    Image path: C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorwks.dll
    Image name: mscorwks.dll
    Timestamp:        Fri Apr 13 15:15:54 2007 (461F2E2A)
    CheckSum:         00564CA8
    ImageSize:        00566000
    File version:     2.0.50727.832
    Product version:  2.0.50727.832
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® .NET Framework
    InternalName:     mscorwks.dll
    OriginalFilename: mscorwks.dll
    ProductVersion:   2.0.50727.832
    FileVersion:      2.0.50727.832 (QFE.050727-8300)

    FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
    LegalCopyright:   © Microsoft Corporation.  All rights reserved.
    Comments:         Flavor=Retail

恩,版本还是比较新的。既然是内存问题,先看GC中有多少object,占用了多少内存

0:000> !eeheap -gc
Number of GC Heaps: 4
------------------------------
Heap 0 (000f3f10)
generation 0 starts at 0x02fad2fc
generation 1 starts at 0x02f83ff8
generation 2 starts at 0x02f00038
ephemeral segment allocation context: none
 segment    begin allocated     size
00109198 7a72c42c  7a74d308 0x00020edc(134876)
000fdfb0 790d5588  790f4b38 0x0001f5b0(128432)
02f00000 02f00038  03081450 0x00181418(1578008)
Large object heap starts at 0x12f00038
 segment    begin allocated     size
12f00000 12f00038  131b00a0 0x002b0068(2818152)
Heap Size  0x47190c(4659468)
------------------------------
Heap 1 (000f50a0)
generation 0 starts at 0x06f5b110
generation 1 starts at 0x06f5acf8
generation 2 starts at 0x06f00038
ephemeral segment allocation context: none
 segment    begin allocated     size
06f00000 06f00038  06ff511c 0x000f50e4(1003748)
Large object heap starts at 0x14f00038
 segment    begin allocated     size
14f00000 14f00038  14f00048 0x00000010(16)
Heap Size   0xf50f4(1003764)
------------------------------
Heap 2 (000f68a0)
generation 0 starts at 0x0af78634
generation 1 starts at 0x0af09d40
generation 2 starts at 0x0af00038
ephemeral segment allocation context: none
 segment    begin allocated     size
0af00000 0af00038  0af92a0c 0x000929d4(600532)
Large object heap starts at 0x16f00038
 segment    begin allocated     size
16f00000 16f00038  16f00048 0x00000010(16)
Heap Size   0x929e4(600548)
------------------------------
Heap 3 (000f7bc8)
generation 0 starts at 0x0ef7b270
generation 1 starts at 0x0ef7b264
generation 2 starts at 0x0ef00038
ephemeral segment allocation context: none
 segment    begin allocated     size
0ef00000 0ef00038  0ef7d27c 0x0007d244(512580)
Large object heap starts at 0x18f00038
 segment    begin allocated     size
18f00000 18f00038  18f00048 0x00000010(16)
Heap Size   0x7d254(512596)
------------------------------
GC Heap Size  0x676638(6776376)

内存占用只有6M,显然不是CLR object导致的问题。那看来真的就是内存碎片了。于是先看看程序中有多少DLL:
0:000> lmf
start    end        module name
00900000 00bc5000   xpsp2res C:/WINDOWS/system32/xpsp2res.dll
01000000 01005000   w3wp     c:/WINDOWS/system32/inetsrv/w3wp.exe
1b740000 1b748000   App_global_asax_incckcvw C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/root/b972f933/24c4c459/App_global.asax.incckcvw.dll
1b770000 1b790000   Boke_WebRoot_Admin C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/root/b972f933/24c4c459/assembly/dl3/0854db20/0aaa279d_a314c801/Boke.WebRoot.Admin.DLL
1b7e0000 1b820000   log4net  C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/root/b972f933/24c4c459/assembly/dl3/8af1019b/00a071ef_de00c801/log4net.DLL
1bb00000 1bb0e000   App_Web_fsrghzyk C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/root/b972f933/24c4c459/App_Web_fsrghzyk.dll
1bb20000 1bb30000   AspNetPager C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/root/b972f933/24c4c459/assembly/dl3/53ce5ce1/00a071ef_de00c801/AspNetPager.DLL
1bb30000 1bb3c000   App_Web_qenznn_e C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/root/b972f933/24c4c459/App_Web_qenznn_e.dll
1bb60000 1bb70000   UDMap    D:/webfolder/dvdvAdmin/bin/Map.dll
50210000 5025c000   SMDiagnostics_ni C:/WINDOWS/assembly/NativeImages_v2.0.50727_32/SMDiagnostics/da4366daf8361c62ed3fcec4c55fa9ca/SMDiagnostics.ni.dll
50270000 50368000   System_IdentityModel_ni C:/WINDOWS/assembly/NativeImages_v2.0.50727_32/System.IdentityModel/bc31a40dee949687576d5395efcab6a0/System.IdentityModel.ni.dll
504e0000 50728000   System_Runtime_Serialization_ni C:/WINDOWS/assembly/NativeImages_v2.0.50727_32/System.Runtime.Seri#/c861896fa11d6eef9fed23cff7b77b01/System.Runtime.Serialization.ni.dll
507a0000 5185e000   System_ServiceModel_ni C:/WINDOWS/assembly/NativeImages_v2.0.50727_32/System.ServiceModel/719a7cce9b36b780b3edd9869ceb2537/System.ServiceModel.ni.dll
5a300000 5a307000   w3tp     c:/WINDOWS/system32/inetsrv/w3tp.dll
5a320000 5a332000   w3isapi  c:/WINDOWS/system32/inetsrv/w3isapi.dll
5a360000 5a36d000   w3dt     c:/WINDOWS/system32/inetsrv/w3dt.dll
5a390000 5a3e8000   w3core   c:/WINDOWS/system32/inetsrv/w3core.dll
5a3f0000 5a3f6000   w3comlog c:/WINDOWS/system32/inetsrv/w3comlog.dll
5a400000 5a408000   w3cache  c:/WINDOWS/system32/inetsrv/w3cache.dll
5a420000 5a431000   iismap   C:/WINDOWS/system32/iismap.dll
5b640000 5b658000   strmfilt C:/WINDOWS/system32/strmfilt.dll
5e620000 5e6da000   Microsoft_JScript C:/WINDOWS/assembly/GAC_MSIL/Microsoft.JScript/8.0.0.0__b03f5f7f11d50a3a/Microsoft.JScript.dll
5f270000 5f2ca000   hnetcfg  C:/WINDOWS/system32/hnetcfg.dll
60060000 60066000   aspnet_filter C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/aspnet_filter.dll
60070000 60075000   aspnet_isapi //?/c:/WINDOWS/microsoft.net/framework/v2.0.50727/aspnet_isapi.dll
608f0000 60901000   admwprox C:/WINDOWS/system32/admwprox.dll
60ba0000 60bb1000   wamreg   c:/WINDOWS/system32/inetsrv/wamreg.dll
62da0000 62da7000   lonsint  c:/WINDOWS/system32/inetsrv/lonsint.dll
637a0000 63d02000   System_Xml_ni C:/WINDOWS/assembly

  • 0
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
ASP.NET Core是一个跨平台的开源框架,可用于构建现代化的云端应用程序分片上传是一个常见的需求,特别是当用户需要上传大文件时。ASP.NET Core提供了分片上传的功能,可以有效地解决这个问题。 通过ASP.NET Core的分片上传功能,大文件可以被分割成多个小片段进行上传,这样不仅可以减小内存压力,也可以提高上传速度和稳定性。同时,分片上传还可以实现断点续传功能,即使在文件传输中断的情况下,用户也可以从上一次中断的地方继续上传文件。 在ASP.NET Core中实现分片上传可以通过多种方式,其中包括使用第三方扩展库或自定义实现。在使用第三方扩展库时,可以通过NuGet包管理器引入相关库,然后按照文档进行配置和调用相应的API来实现分片上传。如果需要自定义实现分片上传,可以通过分析客户端上传的请求,将文件分割成小片段并逐一上传,然后在服务端将这些小片段合并成完整的文件。 值得注意的是,分片上传功能的实现需要考虑文件的完整性、安全性和性能,因此在开发过程中需要进行充分的测试和优化。除此之外,还需要考虑并发上传的情况,以及对上传过程中发生的错误进行处理和日志记录,以提升用户体验和系统稳定性。 综上所述,ASP.NET Core提供了灵活且高效的分片上传功能,通过合适的方法和工具可以轻松实现大文件的上传和管理,为用户提供更好的上传体验。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值