帮客户解决基于surging的物流速运网关内存泄漏问题

一、概述

有surging企业客户找到我,系统已经在线上环境运行,在使用过程中碰到内存不能释放的问题,每次都要和客户打招呼进行重启造成很坏的影响,问能不能彻底解决掉,然后我打包票可以解决,解决不了不收钱,

下面我将把我解决内容分析出来。

。 木舟 (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进行维护)

二、dump文件分析

有了vs,基本上不需要通过windbg进行装逼分析了,通过查看托管堆并没有大型对象,这边没有问题,那就是业务耗时导致线程阻塞。

然后可以看到有50个线程阻塞同步等待消息

通过线程调用的堆栈信息,我们就可以发现dotnetty的work 的执行线程阻塞了

三、代码修改

通过以上分析就可以得出网关在处理Rpc远程调用的时候,未收到及时的返回,造成消息积压,线程进行同步等待,

然后后面去业务端发现dotnetty 在处理业务的时候,是不支持ChannelPipeline的eventExecutor的,所以造成了网关消息的堆积。那么把代码改一下

ChannelRead 还是改成Task.Run

设置以下基于netty 的环境变量

复制代码
1 Environment.SetEnvironmentVariable("io.netty.allocator.maxOrder", "5");//调整 chunkSize 的大小,只能设置0-14范围内的值,默认值11
2 Environment.SetEnvironmentVariable("io.netty.allocator.numDirectArenas", "0");// 设置Direct Arenas,默认核数*2
3  Environment.SetEnvironmentVariable("io.netty.allocator.type", "unpooled");// 不使用内存池
4 
5 Environment.SetEnvironmentVariable("io.netty.allocator.numHeapArenas", "0");// 设置Heap Arenas,默认核数*2

四、运行结果

以下是运行3小时的内存消耗

五、小结

能不能赚到这3.5w,请关注后续。

相关推荐
fanly111 天前
凯亚物联网平台发布测试版本
surging microservice·surging
fanly111 天前
基于凯亚物联网平台优化内存和性能
surging microservice·surging
fanly112 天前
凯亚物联网增加MQTT设备功能测试
微服务·surging microservice
fanly1112 天前
如何搭建基于surging的分布式直播流媒体
微服务·surging microservice
fanly1114 天前
凯亚利用直播推流技术请大家看电影
surging microservice·surging
fanly1118 天前
使用的架构是否满足微服务设计思想?
surging microservice·surging
fanly1120 天前
凯亚IOT平台在线测试MQTT接入设备
surging microservice·surging
fanly1123 天前
凯亚物联网平台如何通过MQTT网络组件接入设备
surging microservice·surging
fanly111 个月前
.net clr 8年才修复的BUG,你让我损失太多了
surging microservice
fanly111 个月前
surging 集成SuperSocket预发布版本2.0
surging microservice