课程咨询 :025-84812726

南京.NET培训 > 达内新闻 > 如何查找.NET程序内存不断上涨的原因
  • 如何查找.NET程序内存不断上涨的原因

    发布:.net培训      来源:南京达内      

  • .net培训资讯:前段时间公司新写的自动升级服务端(Remoting)出现了内存不断飙升的情况,从最初的七八十兆一晚上竟然飙到了1G多,直接导致客户端连接服务端失败,这不科学,后来优化了各种可能造成占用内存的方法(数据库连接,I/O操作,引用类型释放),但效果不佳,这下可难为我们了,不知道问题的所在也就不知道该如何去修改。

    我们知道.NET是带有垃圾回收机制的,出现这种情况一般是由某些数据长期存活在内存中又不能被当成垃圾数据回收的原因造成的。

    后来就在各搜索引擎上进行了各种搜索,有说使用windebug分析dump,但需要大量时间琢磨,有人说是不是硬件问题,还有人说中毒了,最后找到了一款微软推出的CLRProfiler工具,貌似很强大,遂MSDN了一把,MSDN是这样说的:

    Who allocates what on the managed heap.

    Which objects survive on the managed heap.

    Who is holding on to objects.

    What the garbage collector does over the lifetime of your application.

    得到这些信息以后就决定使用一下,让服务端运行了一会儿,停止以后得到分析结果,最终在Allocation Graph视图下了解到原来是下载文件DownloadFile方法下的byte[]数组引起的,短短不到一分钟的时间竟然占用了两百多兆的内存,好了,这下可找到“原凶”了,有得折腾了

    方案1:把要下载的数据一并加载到内存,用户在下载的时候通过position来获取byte[]不新建直接返回,是能解决问题,但这就大大降低了服务端的可用性啊,只能当做小文件服务端,太不合理。

    方案2:由于下载文件的时候返回的是一个可序列化的类,所以想是不是这里出现了问题,可以直接返回byte[],以最基本的数据头->数据长度->数据->数据尾来实现,但这样一来要改的东西太多了,服务端客户端,协议重构,眼看着就要落幕的项目却要重头再来心有不甘那,再加上还有一堆任务在后面赶着,这不是坑自己吗,也放弃了。

    然后又回到各种网络资料搜索上,经过一番查找后了解到,byte[]最终也是会被回收的,只要是托管的数据都是能被回收的,只是周期可能会长一些,最后又回到了Remoting本身上,抱着试一试的心态把WellKnowObjectMode由SingleTon改为了SingleCall,跑了一晚上最后稳定在了200M上下,总算松了口气。

    使用SingleTon本来是想节省内存消耗的,可没想到得不偿失如此的大费周折,遂总结出SingleTon并不适合并发量大的服务端程序,SingleTon是单线程模式,在调用每个方法的时候都会被加锁,猜测造成数据一直不能被释放的原因是由这些锁造成的,由于连接的数量太多导致连接一直处于排队状态,造成了后面连接的客户端响应过慢,连接超时,在这里也给大家一个教训还是用SingleCall实在。

    上面说了这么多只是跟大家分享一下解决问题的经验,还有叙述了一下问题的所在,如果各位有不同的见解请一定要指出来,毕竟.NET内存分配、垃圾回收本就比较复杂。

    推荐文章

上一篇:Borland投奔微软.NET整合项目

下一篇:ASP.NET中的Cache使用介绍

最新开班日期  |  更多

.NET工程师--全日制班

.NET工程师--全日制班

开班日期:04-28

.NET—零基础周末班

.NET—零基础周末班

开班日期:04-28

.NET—零基础全日制

.NET—零基础全日制

开班日期:04-28

.NET工程师--周末班

.NET工程师--周末班

开班日期:04-28

  • 地址:南京市龙蟠中路30号东来商务中心A座5楼
  • 课程培训电话:025-84812726     全国服务监督电话:400-111-8989
  • 服务邮箱 tousu@tedu.cn
  • 2001-2016 达内时代科技集团有限公司 版权所有 京ICP证8000853号-56