.net clr 8年才修复的BUG,你让我损失太多了

一、概述

.NET社区修复问题可谓是龟速,一个BUG在.NET 7.0+版本才修复,你让我损失了几万块,我现在还记得客户那种质疑的表情,你了解那种尬尴的气氛吗?你让我一度怀疑dotnetty,我从来不去怀疑框架,运行时,每次碰到问题,我先提醒使用者先去找自己的问题,现在让我改变了这个看法。

凯亚 (Kayak) 是什么?

凯亚(Kayak)是基于.NET6.0软件环境下的surging微服务引擎进行开发的, 平台包含了微服务和物联网平台。支持异步和响应式编程开发,功能包含了物模型,设备,产品,网络组件的统一管理和微服务平台下的注册中心,服务路由,模块,中间服务等管理。还有多协议适配(TCP,MQTT,UDP,CoAP,HTTP,Grpc,websocket,rtmp,httpflv,webservice,等),通过灵活多样的配置适配能够接入不同厂家不同协议等设备。并且通过设备告警,消息通知,数据可视化等功能。能够让你能快速建立起微服务物联网平台系统。

凯亚物联网平台:http://117.72.121.2:3100(用户名:fanly 密码:123456)

链路跟踪Skywalking V8:http://117.72.121.2:8080/

surging 微服务引擎开源地址:https://github.com/fanliang11/surging(后面surging 会移动到microsurging进行维护)

二、压测分析

通过jmeter分析,高并发是没问题的,带宽一直是跑满的。

内存也没问题

但是你会发现,运行11天后内存就增长到1g多,每天要增长100多mb

三、用dump 分析

用vs 分析指出是dotnetty 的 ManualResetEventSlim 导致的,但是我看了代码没有问题啊,让我思绪有些混乱,就让我手足无措,甚至想下载dotnetty 把ManualResetEventSlim去掉试试,后面我发现mono社区有人讨论ManualResetEventSlim内存泄漏的问题,还是2020年提出的,一直没解决,后面2023年有人重提这个问题,有人回复这个问题是由于Queue删除队列没有把元素的引用一起删除导致的内存泄漏,而后在.NET 7.0把这个问题修复了。

原帖讨论:https://github.com/mono/mono/issues/19665

有人找到原因,在.NET CORE3.1 问题依旧存在

2023年重提这个问题

然后给出回复是.NET7.0 已经修复

然后surging和kayak 升级到.NET 8.0 ,启用几十个组件和协议,内存在70,80MB左右。后续观察内存是否还会增长

相关推荐
fanly118 天前
如何搭建基于surging的分布式直播流媒体
微服务·surging microservice
fanly1110 天前
凯亚利用直播推流技术请大家看电影
surging microservice·surging
fanly1115 天前
使用的架构是否满足微服务设计思想?
surging microservice·surging
fanly1116 天前
凯亚IOT平台在线测试MQTT接入设备
surging microservice·surging
fanly1119 天前
凯亚物联网平台如何通过MQTT网络组件接入设备
surging microservice·surging
fanly111 个月前
surging 集成SuperSocket预发布版本2.0
surging microservice
fanly111 个月前
通过jmeter压测surging
surging microservice
fanly111 个月前
帮客户解决基于surging的物流速运网关内存泄漏问题
surging microservice
fanly111 个月前
从木舟平台来庖丁解牛微服务
surging microservice