背景:
并行计算时,本机TR服务会调用其它服务器TR服务,进行计算,得到结果,最后本机汇总结果,返回给调用方。
现在有四台服务器,sd,sd1,sd2,sd3。现在把sd配置成软负载,而sd1,sd2,sd3配置成硬负载。
关注点:
本机调用,20个线程,运行10000次,执行两次,直接调用sd的服务,不调用sd1,sd2,sd3,来测试分发功能是否OK。此时只关注分发量是否平均,不关注是并行计算处理内容是否正确。
问题:
进行分发测试后,统计结果,进入到logs/sofa目录下,查看sofa-sal-digest.log文件
grep '10.253.69.103'sofa-sal-digest.log|grep callDataPoint -c 进行统计
发现10.253.69.103这个105109次,而10.253.69.104为0次,而10.253.69.105为106767次,根据平均分配原则,此次104的机器肯定有问题。(数据不完全一致因为有其它调用的原因)
排查:
1. 怀疑服务器未启动,查看java进程及8080/services服务,进程OK,服务OK。
2. 怀疑代码未更新,更新流,重新部署,运行后结果仍不正确。
3. 怀疑服务发布失败,进入sofa-boot.log日志进行查看,发现果然未启动成功。
4. 怀疑TR服务问题,其它TR服务OK。
5. 怀疑配置中心挂掉,服务注册失败,发现配置中心OK,其它TR服务发布成功,且未有出错日志。
6. 怀疑流的信息被改,果然,吐血!
感想:
上述问题是与开发共同排查的,在排查的过程中,发现自己的思路不清晰,而开发比较清楚,原因在于我们对系统的启动流程、SOFA框架不熟悉导致的。因此还要加强框架及部署系统整个流程的关注。我们现在排查系统层面的问题现在还很弱,原因是对这块不了解,所以还是要加强了解,了解的够多,明白调用关系和加载顺序,深入懂得原理,才会手到病除。