一次生产环境CPU占用高的排查

1. 项目背景

甲方是保密级别非常高的政府部门。所以我们全程拿不到任何测试数据，只能是自己模拟数据进行测试。

项目部署的时候，公司派了一人到甲方现场，在甲方客户全程监督下，进行部署，调试，导入数据等工作。因为前期看不到真实的数据，所以很多功能都是凭客户口述进行，到了现场难免发现问题。

这时需要改动代码重新打包部署，需要客户特制U盘需入密码才能传到内网。总之，非常麻烦。

如果有什么BUG，全靠同事口述。如果是功能性的什么BUG还好，沟通虽然困难，大体都能很快解决。

但是，对的，“但是”虽迟但到，同事在现场遇到一个所谓"很奇怪"的问题。当导入某一批文件的时候，程序就卡在那里不动了。

2. 技术背景

长话短说就是，通过页面批量上传文件，后端接到文件后会做一些word,pdf转换按页按段落提取文字，并通过消息队列kafka异步进行下一步处理：包括不限于语义分析通过算法提取出关键要素，以及要素之间的关联等等。

嗯，不涉及具体业务，不算涉密。

同事描述的现象包括：

• 1.程序卡住了
• 2.kafka报错了
• 3.算法返回500
• 4.重启了spring boot应用，kafka,算法服务都没法恢复。

以上是同事在现场用手机打字交流的一个简单复盘。非严格按照时间线来的。

2.1 程序卡住了

同事只给出了程序卡住的现象描述，没给能出具体的节点。我只能通过不停的加日志来确定具体卡在哪里。

最终确定卡在某个算法调用期间。

结合同事曾说过算法调用出了问题，看看算法问题。

2.2 算法问题

算法是我使用django封装了一个python web接口。具说http请求返回了500，那应该是web服务内部异常。

但是奇怪的是，同事说算法日志没有看到异常信息。

因为NLP涉及到vocab,如果有生僻字或者vocab文件里不包含的字符，可能会导致算法异常或者解析异常。

但同事反馈说没有相关的异常。

2.3 kafka报错了

这应该是一个乌龙。

我在spring kafkatemplate发送消息的时候打印了回调消息。

    * 向kafka发送doc相关信息
     * @param info
     */
    public void sendDocInfo(String info) {
        this.template.send(docTopic, info);
        ListenableFuture listenableFuture = this.template.send(docTopic, info);
        boolean bool = listenableFuture.isDone();
        log.info("kafka发送状态 :" + bool);
    }

在某个算法调用期间一直卡住，超过了kafka默认的5分钟的限制，返回了false。

换句话说，这里的日志不能表明kafka出了问题。它只是程序卡住的一个连锁现象反映，远不是本质原因。

2.4 重启服务都没用

兜兜转转，打包上传到现场，客户再手动导入。时间一步步流逝。

听到同事说重启了spring boot应用，kafka,算法应用都没用以后，我一度有点懵逼了。

如果是某个线程一直空耗没释放，一定会导致CPU升高，（这里插一句，提过top jstack查看CPU高的线程的堆栈日志），但是重启应用肯定会释放的呀。

这怎么会重启了还是这样呢？

小半天就这么过了，下午5点客户就催下班了。又是羡慕体制内的一天。

3.重新确定方向

经过一晚的大脑放空，我觉得不能被零散的信息牵着鼻子走。

我觉得我应该放过多余信息，直捣黄龙。

程序卡住了？这种系统假死问题，第一反应肯定是查看CPU啊，有没有占用CPU高的进程，再查看应用里具体的是哪个线程在占用着cpu,再通过jstack找到具体的应用代码。

就算是最后不是这个问题，以上操作也是一个非新手程序员的基操啊。

而且，为什么重启应用后会重现卡住的现象？因为kafka啊。

kafka为了确保不丢消息。在生产端，集群，消费端都需要做出努力。当然，这其实不是kafka独有，任何消息队列都是相同的思路。

具体到kafka消费端，为保证不丢消息，至少保证在没有异常的情况下才做ack.

当程序假死的时候，没有执行ack操作，那么当程序重启的时候，kafka当然会去做重新拉取信息的动作。又造成程序假死。

这很合理，完全可以说得通。

当然这只是我上班路上的推测。

一大早，新的一天，一切清零。到公司，跟同事说了，他重启了程序，没有上传文件，通过后台日志，观察到kafka确实在消费之前的数据。

很好，验证得到证实，完美的开始。

接下来，就是通过top命令查看是否有CPU占用高的现象。

涉密项目哦，可不敢可没有截图哦。

同事说到有个进程占用CPU超过100%，从占用时间上推测，从重启过后就一直没释放。

非常好，验证了第2个猜想。

再通过 top -H -p pid命令得到应用内占用CPU高的具体线程。将线程ID转为十六进程，再通过jastck grep 线程码就可以定位到具体的代码。

具体的定位过程因为项目原因，不便不能展示过多，技术方面的细节参考我的另一篇文章(【工作随手记】deaklock排查)

告诉同事重点查看带有自己公司包名的代码，很快就定位到了代码位置。

因为完全与业务无关，可以把代码放上来。

/**
 * 获取一个字符串和关键词，查找这个字符串出现的次数
 * @param str 原文
 * @param key 关键词
 * @return
 */
public static int getStringCount(String str, String key) {
    int count = 0;
    int index = 0;
    while ((index = str.indexOf(key)) != -1) {
        count++;
        str = str.substring(index + key.length());
    }
    return count;
}

看到这个while我一瞬间就知道，症结找到了。

当传入的关键词为""空串时，直接就会陷入while死循环。这就是程序假死的本质原因。

4.总结

从一下午找不到重点，到第二天半小时解决问题。我也在思考，这中间的差异出了什么问题。

项目的特殊背景，是一个原因，但不是主要原因。身处这个行业，以后总要有这方面的需求和场景，不能每次都拿项目特殊性来背书和推脱。

我觉得以下几点是我从这件事当中学到的，在今后的工作的应该尽量避免或者学习的。

• 1.技术人应该相信自己的直觉。
• 2.沟通应该要有效率。要有目的。区分主次。
• 3.从纷繁的反馈中提取有效的信息，是一种能力且可锻炼。
• 4.保持清醒的大脑。否则，宁愿停下来。