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

 一、概述

      有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进行装逼分析了,通过查看托管堆并没有大型对象,这边没有问题,那就是业务耗时导致线程阻塞。

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

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

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

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

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

三、代码修改

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

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

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

 ChannelRead 还是改成Task.Run

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

 设置以下基于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小时的内存消耗

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

五、小结

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

发表评论

您必须 [ 登录 ] 才能发表留言!

相关文章