.Net程序内存异常解析

本文分享了作者解决线上内存异常问题的经历,涉及日志组件优化、内存泄漏查找及消息队列处理。通过分析日志、使用性能分析工具,发现了tcp服务连接问题、内存占用大的消息队列和同步方法等问题,并提出相应解决方案,如多线程处理队列、减少磁盘I/O、优化socket通信和使用异步方法。
摘要由CSDN通过智能技术生成

一、概要
大概在今年三月份的时候突然被紧急调到另外一个项目组解决线上内存异常问题。经过两周的玩命奋战终于解决了这个问题这里把心路历程及思路分享给大家。希望可以帮助到各位或现在正遇到这样事情的小伙伴提供一些思路。

二、场景
当部门老大找到我的时候,给我描述了这样一段话。

“目前服务出现了提交内存异常的问题,目前分析出来可能是日志组件有大量的日志消息堆积把内存占满导致服务崩溃了。在国内某地区客户的服务器上15000台物联网设备不能正常工作这个问题非常紧急需要马上解决。”

问题描述至此,没有其他可用信息。这时候我先崩溃了…但是任务找到你不能说不行。万一解决了这种重大事故还能在部门老大面前秀一把。

三、思路
(1)分析
Part1,分析日志堆积原因
拿到服务器地址去翻出日志文件,查看日志内容;内容基本上都是一些报错情况xxx对象为null,对象转换失败。
日志组件的实现也比较糟糕Log对象在每个调用的类里都会重新new
解决方案:

修复对象为null的问题并加上空值判断,大概的原因就是json值转换的时候传入的值是null那么就引起这两块的连锁反应。非常值得注意的一点是通常json对象转换的地方都会加入try块去捕获异常在程序里try的捕捉是会对.net程序造成性能影响的所以能用判断规避的尽量不要去触发try机制,程序性能被拖下去其他方面的处理就会变相的削减处理速度变慢那么数据堆积好像就解释的通了。
将日志组件重构为单例且线程安全的实现,写入日志的数据结构体是class这里改成struct,考虑的因素是引用类型会存在引用问题再就是考虑的值类型和引用类型在内存中占用的大小是不一样的,而且值类型和引用类型在处理速度上值类型更快。
以为这样就结束了吗?不,当程序改好之后放在测试服务器上跑第二天早上测试部的小姐姐就找到我说异常报错情况是好了,但是内存泄漏还是

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值