记一次CPU有规律飙高的线上问题排查过程

一、背景

最近在计费系统模块和灰度发布相关的功能已经基本交付，在这个间隙中，领导说有个线上问题需要排查下，
问题的场景比较有意思，排查过程中也有一些成长，这里记录一下。

二、排查过程

2.1 查看pinpoint 监控

首先根据领导的反馈看pinpoint中的JVM的CPU日志：

CPU每隔一个小时会有一个突刺，对于平时的表现来看有个波峰。而且通过不同时段的波峰的表现看是相对有规律的，同时波峰的持续时间也是不太固定的，有时候是2-4分钟，有时候是将近10分钟，另外发生波峰的时间点大多在每个小时的前10分钟左右，如下监控显示：

2.2 排除FGC的影响

因为最近上线该服务的时候我们修改了JVM的启动参数，领导说可以明确没有GC，这里我也看了JVM的启动参数：

另外就是堆内存和非堆内存的监控也没有明确有GC的影子，所以这里先排除FGC的影响。另外一方面如果出现CPU利用率飙高的情况下之前遇到的都是接近百分之百，目前基本是75%左右。

2.3 查看ELK日志-SQL部分

这里先看一下该服务在处于CPU飙高的时间段内SQL方面的监控日志：

排查如下日志：

[cn.xxx.dao.xxMapper.selectByxxxIdAndRound]-[debug]:<== Total: 1

这里主要看SQL内容和Total字段返回的条数，但是基本上没有发现问题，可以排除是SQL 方面的原因了。

2.4 查看缓存代码

由于之前做过分布式本地缓存刷新的方案和落地，所以就敏感的去查一下本地缓存方面的代码，因为有个关键点是本地缓存用Guava构建的，同时注释说明是每个小时构建一次，这里我们看一下构建代码：

CacheLoader<String, Map<String, Object>> loader =
    new CacheLoader<String, Map<String, Object>>() {
   
        @Override
        public Map<String, Object> load(String key) throws Exception {
   
            return loadInfo(key);
        }

        @Override
        public ListenableFuture<Map<String, Object>> reload(
            final String key, Map<String, Object> voiceSiteInfo) {
   
            ListenableFutureTask<Map<String, Object>> task =
                ListenableFutureTask.create(
                    new