针对大并发下SPRINGBOOT+DUBBOX问题排查总结

揭语:惟精(精纯专一心境)---人心惟危,道心惟微,惟精----借用朱熹格物精神!

   摘要:缘自断断续续听同事说生产在运行高峰期前段出现pending状态,一直无暇东顾,总有期望人心(其他人员)会诊断此问题---人心惟危,撰写本篇内容的前一天接到部门核心人的的讯息,需要处理此问题---道心惟微,从而转入惟精状态(历时两天两夜),彻查springboot+dubbox的在微服务下出现的pending状态,导致用户登录不成功,重启之后正常!技术部分写得比较粗略(描述故弄玄虚,涉密等,希有志者关注交流),

诊断过程:

      一、排查过程

           1、数据库反应

               查阅日志,数据库出现FAILD状态的日志与出现pending状态无前后文,时间序列关系--时间、文体空间无关联,剔除数据库反应错误!

           2、所有线程池的排查(dubbo线程池、redis线程池、tomcat线程池、zookeeper线程池等等)

                    线程池的计算=计算机CPU核数*1000(预估数)

                    修改使用到中间件线程池为预估值*3的安全空间,重新部署系统,历时:20多个小时;

                    结果:高峰期外网的消费者端服务问题依旧。剔除

           3、网络情况(网络交互中瞬时的最大吞吐量)

                消费者端---服务提供者,最大字节修改为默认值的3倍左右。

                网络流程监控1.7m,正常范围内!

                结果:问题依旧。剔除

          4、加入调用方法探针:监控(QPS,AVGTIME等)

               下图:

                针对大并发下SPRINGBOOT+DUBBOX问题排查总结

 

 

                                         总调用情况:测试截图

                   针对大并发下SPRINGBOOT+DUBBOX问题排查总结

 

                                 方法调用监控截图:

                历经高峰期后:有了新的生机,但问题依旧。

               结论:服务之间网络动波动导致延迟超时调用,线程数居高不下!修改对应的线程池个数后。部署-----不能剔除(socket连接数占用内网环境,导致消息中间件socket服务推送和订阅频率过高),                          服务器网络过载,消息消费滞后,降低推送评率)

          5、承4:dubbox的节点重试3次,导致此问题,修改注册方式,等待问题进一步重现!

                       

                无量惟精!惟精!惟精!

 

                   

              

 

上一篇:NetSuite 为啥销货成本会变


下一篇:kubenetes学习笔记(4)