前段时间，我们的项目上线没多久之后，发现有2个服务后台进程CPU一直在100%-400%左右，重启应用进程后会好一些，半个小时之后CPU又会飚上来。跟开发架构师说了这个情况，当时没有做详细的检查，只是发现IO比较高，因为线上的环境日志级别为info，所以打印的东西特别多，开发建议先把日志级别改低，改成了ERROR级别。（其实仔细想想，肯定不是这个问题，因为一台服务器上面总共有十五六个服务，而出现CPU过高的服务就是2个，所以如果是因为IO过高的话，那么其他几个服务也应该会有问题）
改了级别之后问题依然存在，在那几天真是煎熬，因为CPU一旦过高的话有时会导致整个服务不可用，公司销售部门一堆人在叫，有时凌晨两三点还要起来重启服务器。后面通过jstack命令查看对应的进程的dump文件，发现是消费队列那一块的代码有问题，但具体是什么问题没有定位出来，然后开发给了一个临时解决方案，先把消费队列与业务的代码拆分开来，比如原来的A服务拆份成A和Ａ-consumer服务，B服务拆分成Ｂ和Ｂ-consumer服务，拆分后服务还是放在原来的服务器上面。拆分后确实如之前说的，A服务和B服务的CPU正常了，但是A-consumer和B-consumer服务的CPU会很升高，而且达到一定程度时，整个服务器的CPU会达到100%，这时服务器上面的所有服务还是都会受到影响，导致一些偶尔不能访问。后面跟我们的技术总监讨论如何处理时，他建议把consumer的服务单独部署到两台服务器上面，这样做的话就算是A-consumer和B-consumer进程的CPU很高的时候，也不会影响到其他业务的正常，最多只是影响了mq队列消息的消费。
根据建议部署名后，正常的业务不受影响了，但是由于消费队列的服务经常出问题，导致数据不准确，也是被公司销售部门不停吐槽。但开发一时半会又没找到解决办法，所以作为测试同时又作为运维的我就苦逼了，一天到晚提醒吊胆的，而且经常半夜起来处理服务器的东西，因为当时也做了服务的监控，每天收到的报警短信就有一两百条，也是够心烦的。
就这样提心吊胆又过了一周，其实在这一周的过程序中开发也试过很多种方法，比如把mq 队列的连接数改小，同时把spring cloud中的很多能优化的配置参数都优化了一遍，但问题依然存在，终于在过完上一周之后，公司的技术总监终于在代码中找到了问题，那就是连接mq进行消费时的封装类里面有一个重复创建对象的方法，这个方法会导致每消费一个队列消息就会去创建一个对象，而这个对象的释放不会及时释放。其实他当时也不敢确定就是这个问题。后面先改了其中一个服务，重新部署新代码后，问题解决了，CPU不再升高，一直保持在13%左右。运行了一天之后，该服务的CPU也是正常的。后面把另外一台服务也重新部署，至此，这个持续了快2个月的问题终于解决了。心累啊。
后记：
1、其 实在这里需要说明一下，因为我们的服务比较特殊，消费队列的数据特别多，一天大概在1500W条左右的数据，但这种情况在测试环境下根本测试不出来。所以对于这种问题的测试，不知道有没有什么好的可实现测试的方法？我想到的可能就是一种笨办法，自己用几台测试机不停的调用产生列列的接口和消费队列的接口，但是数据好像还是不够哦。。。
2、关于问题的分析，在整个过程中我们走了很多弯路，而且整个时间耗得很长，这足以说明我们的经验不足，但另外有一点值得借鉴的就是要懂得分轻主次，像把消费队列的业务单独拆分出来，然后部署到另外的服务器上面，这样就不会影响整个业务流程。虽然有些数据会乱，但好歹也能保证业务正常进行。
网友评论