生产服务CPU飙高分析

2021-02-24

生产中，随着扫码相关提供的服务大量接入，高并发为服务带来了不稳定性，主要体现在机器状态很差 CPU经常飙高至1500%以上.

第一次优化

生产CPU飙高，我们可以猜测主要是因为俩个方向影响：

1、大量计算在消耗CPU

2、大量线程和程序上下文频繁切换导致拖累CPU

问题一开始，我是定位到了第二个点，因为我根本没考虑大量计算会消耗，这也是问题分析比较不好的习惯，以己度人。我用自己可能常见的分析去揣测，这是比较傻的行为。

对于一开始认为的第二个点，主要优化了Tomcat的一些参数，对于连接数和线程池的分析，参考了文章。【1】然后有了如下的大致估计量和参数

 # Tomcat
server:
  tomcat:
    uri-encoding: UTF-8
    #最小线程数
    min-spare-threads: 500
    #最大线程数
    max-threads: 800
    #最大链接数
    max-connections: 6500
    #最大等待队列长度
    accept-count: 1000
    #请求头最大长度kb
    max-http-header-size: 1048576
    #请请求体最大长度kb
    max-http-post-size: 2097152
  	#链接建立超时时间
  	connection-timeout: 12000

第一次优化后，有了如下的效果。大致下降到800%左右的。但任然是超高的负载。

其实对于后面模拟测试也可以发现，线程的数量取舍也比较重要，模拟下来大多都是block的线程而且内存cpu都呈锯齿状，可以说明资源短时间内其实是过剩的

所以第一次的数值是具有问题的，没有摸清性能拐点在哪里。

第二次优化

在苏彭的帮助下，详细了解了tomcat一些线程的参数。上面所示的参数对于单个节点来说，负载相当大

#最大链接数
max-connections: 6500
#最大等待队列长度
accept-count: 1000

尤其这俩个参数的设置，会把线程等待拉到很高的值。相对于CPU就是很高负载。

所以稍微调整一下参数，一个对于单个节点相对合理的参数（因为鉴权这个服务本身就是高并发的，所以最小线程我们也调整的很高，对于慢热的那种系统，建议此数值适量调低）

# Tomcat
server:
tomcat:
uri-encoding: UTF-8
#最小线程数
min-spare-threads: 400
#最大线程数
max-threads: 500
#最大链接数
max-connections: 4500
#链接建立超时时间
connection-timeout: 12000

服务代码中也优化了一处，有个作为常量的HashMap，也修改为了ConcurrentHashMap

对于HashMap在高并发在发生死循环CPU飙高，可以查看详细介绍【1】

至此，每个节点忙时峰值CPU大概下降到300%