系统Cpu利用率降低改造之路

一.背景

1.1 系统背景

该系统是一个专门爬取第三方数据的高并发系统，该系统单台机器以每分钟400万的频次查询第三方数据，并回推给内部第三方系统。从应用类型上看属于IO密集型应用,为了提高系统的吞吐量和并发，我们引入了协程(Quasar框架)。由于业务的特殊性,高峰期的时候我们需要管理快300台机器，抛开单台机器每个月成本不算，光是通过后台管理系统更改快300台机器的配置和将机器出局Ip加入到第三方代理提供商的白名单中这一过程就比较繁琐，且容易出现问题。为了解决这一历史遗留问题,降低机器成本，以及提高运维效率，就有了下面的改造之路。

1.2 知识背景

1.2.1 什么是平均负载

平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。它不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待 I/O 的进程。

1.2.2 什么是CPU使用率

CPU 使用率，是单位时间内 CPU 繁忙情况的统计。

1.2.3 平均负载和CPU使用率的关系

CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。

二.发现与猜想

2.1 发现问题

通过监控发现我们的系统单台机器(8C,16G)的CPU利用率竟然维持在80%-90%左右,负载接近过载

在这里插入图片描述

由于我们的系统是IO密集型应用，理论上CPU利用率不可能这么高，所以就需要分析为什么CPU利用率高，CPU利用率过高会间接的导致CPU负载过高，导致CPU队列中的任务调度不过来，从而出现吞吐量降低，扫描次数下降等问题。

2.2 猜想

根据经验我们猜测是不是代码里面出现了耗时计算,死循环,大量序列化反序列化等会导致CPU升高的操作。

三.分析问题

3.1 猜想一:并发过高导致日志打印过多

根据框架同事反馈，我们系统每分钟大概向CLog日志系统输出1G左右日志，经过分析发现是由于日志报文过大且量级较多导致。为此在不影响业务的情况下，我们采用了抽样的方式向日志系统输出日志。分析代码底层我们输出日志时存在序列化有可能导致CPU飘高，为此我们采用了直接调用对象的toString方法直接转换成String输入。但是发上线上后，CPU利用率整体只下降了1%~2%,效果不是很明显。

3.2 猜想二 :压缩回推业务数据导致CPU高

由于系统原先部署在公司外部，回推数据的报文较大且是外网和内网交互，当时带宽不足，可能会出现数据丢失现象，所以当时做了数据压缩功能。我们猜测是不是由于压缩数据存在计算逻辑而导致CPU过高。由于目前目前系统已迁入公司内部，内网之间交互无需考虑带宽的影响，经过验证我们发现可以关闭压缩功能，发上线上后，效果仍然不明显，CPU利用率整体只下降了3%~4%左右,效果仍然不是很明显。

3.3 猜想三: 代码中存在常量字符串频繁反序列化成对象操作

经过上述两个优化后，我们的CPU利用率降了4%~6%左右，但是远远没有达到我们的预期，为此我们开始分析业务代码，通过Arthas(Arthas 是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率)分析占用CPU较高的堆栈信息。我们发现有些类中定义一个静态成员变量,每次调用方法都将该成员变量反序列化成一个对象，在并发高的场景下，频繁的反序列化，显而易见会产生性能问题。下面只列举其中一个，在每次调用test方法时，都将SPECIAL_SEAT_NAME_MAPPING这个常量反序列化成一个Map，并且每次都会将Map中value切割，底层采用的是正则很明显会有效率问题。

public class Test {private static final String SPECIAL_SEAT_NAME_MAPPING = "{\"3\": \"硬卧|二等卧\", \"J\": \"二等卧|硬卧\",\"4\": \"软卧|一等卧\", \"I\": \"一等卧|软卧\"}";private void test(SeatInventory seat, String seatTypes) {if (StringUtils.isNotBlank(seatTypes)) {HashSet<String> seatTypeList = Sets.newHashSet(seatTypes.split(""));Map<String, Object> specialSeatNameMap = JacksonUtils.toMap(SPECIAL_SEAT_NAME_MAPPING);for (String seatCode : seatTypeList) {String special_name = String.valueOf(specialSeatNameMap.get(seatCode));String oldName = seat.getSeat_name();if (StringUtils.contains(special_name, oldName) && !StringUtils.startsWith(special_name, oldName)) {seat.setSeat_name(Splitter.onPattern("\\|").splitToList(special_name).get(0));}}}}
}

更改后代码如下:将反序列化操作前置，避免每次都反序列化对象，并将其中对value进行切割的操作也前置，避免每次都切割，以此来减少性能开销。经过此次更改CPU利用率竟然下降了**8%~12%**左右。

public class Test {private static final String SPECIAL_SEAT_NAME_MAPPING = "{\"3\": \"硬卧|二等卧\", \"J\": \"二等卧|硬卧\",\"4\": \"软卧|一等卧\", \"I\": \"一等卧|软卧\"}";public static final Map<String, List<String>> specialSeatNameMap = new ConcurrentHashMap<>();static {Map<String, Object> result = JacksonUtils.toMap(SPECIAL_SEAT_NAME_MAPPING);for (Map.Entry<String, Object> entry : result.entrySet()) {String specialName = String.valueOf(entry.getValue());List<String> specialNameList = Splitter.onPattern("\\|").splitToList(specialName);specialSeatNameMap.put(entry.getKey(), specialNameList);}}private void test2(SeatInventory seat, String seatTypes) {if (StringUtils.isNotBlank(seatTypes)) {HashSet<String> seatTypeList = Sets.newHashSet(seatTypes.split(""));for (String seatCode : seatTypeList) {List<String> specialNameList = specialSeatNameMap.get(seatCode);String oldName = seat.getSeat_name();if (CollectionUtils.isNotEmpty(specialNameList) && specialNameList.contains(oldName) && !Objects.equals(specialNameList.get(0),oldName)) {seat.setSeat_name(specialNameList.get(0));}}}}
}

3.4 猜想四: 系统中存在大量深拷贝

通过Arthas命令我们发现，系统内存在大量JacksonUtils.toBean和JacksonUtils.toList调用来实现深拷贝功能，查看代码我们发现由于数据只有一份，会对这一份数据进行过滤并更改数据中的某些字段的值，所以需要拷贝两份完全一样的数据，来达到更改数据互不影响对方的属性值。由于采用的是序列化和反序列化的方式来生成新的对象，这种方式在并发高的系统中是及其消耗CPU的。下图是Arthas打印的Cpu利用率占用较高的堆栈信息。
在这里插入图片描述

为此我们决定在不影响业务的前提下寻找一种能实现深拷贝且不怎么占用CPU资源的方式来替代目前这种方式。经过调研几种能实现拷贝的工具Spring的BeanUtils.copyProperties，Apache BeanUtils.copyProperties发现都存在很多坑。对于List的拷贝是属于浅拷贝，需要自己写兼容逻辑才能实现深拷贝，并且底层采用反射的方式从一定程度上来讲，采用反射的方式在并发高的情况下也会出现性能问题,不仅不能解决目前的问题，可能还要引发其他问题。对此我们采用了最原始的方式，采用new 对象的方式来实现深拷贝。经过这次的优化CPU利用率直降20%~25%。

四.结果

经过上述优化我们系统的CPU使用率从原先的80%-90%左右直接下降到了30%左右，负载也由原来的接近过载降到了原先的三分之一，我们发现原先我们单台机器每分钟查询8W次会出现瓶颈，按照优化之后理论上我们可以单台机器可以每分钟查询24W次，这样原先需要3台机器才能满足的查询次数现在只要1台机器就可以满足。

4.1 优化前后CPU利用率对比图和优化后负载情况

在这里插入图片描述

4.2 增大并发后CPU利用率和负载情况

在这里插入图片描述
从上图可知，当我们将并发增大至原先的三倍，CPU利用率甚至比原来的还要低，负载也比原先的低，说明我们的优化后的结果是符合我们的预期的查询第三方系统的次数从原先单台机器的每分钟8W多次变成了每分钟24W多次，平峰期我们日常需要维护90台机器可以直接缩减成30台，高峰期维护的300台机器可以直接缩减成100台，不仅每年可以直接为公司省去机器成本几十万,在机器的管理上也更加方便。