服务优化实践-阿里云开发者社区

性能分析常用方法

1. top

top指令默认用来监控cpu使用情况，根据cpu使用情况，分析整个系统运作情况（大多数系统cpu密集型）

top指令查询的进程，将会根据cpu使用率大小进行排序，使用的比较多的排在前面，也可以按照内存进行排序，如果需要按照内存排序：按一下m键；

Load verage: 1分钟cpu平均使用率 5分钟cpu平均使用率 15分钟cpu平均使用率

单核cpu（1个核心cpu）:

Load average < 1 , 表示cpu毫无压力，比较空闲，运行流畅

Load average= 1, 表示cpu刚刚被占满，没有可提供的cpu资源了

Load average>1，表示cpu满负荷运作，线程处于阻塞状态，等待cpu资源了

Load avergage > 5 , 表示cpu线程严重阻塞，如果时间一长，系统可能被打垮

4核cpu（4个核心cpu）:

Load average < 4 , 表示cpu毫无压力，比较空闲，运行流畅

Load average= 4, 表示cpu刚刚被占满，没有可提供的cpu资源了

Load average>4，表示cpu满负荷运作，线程处于阻塞状态，等待cpu资源了

Load avergage > 20 , 表示cpu线程严重阻塞，如果时间一长，系统可能被打垮

2. free

free 排查线程内存问题重要指令，存在问题很多情况下也会使得cpu使用率飙高

3. df

df指令排查磁盘使用情况，有是时候服务出现问题，可能是磁盘不够了。

也可以使用du命令查询磁盘空间情况：

du命令： du -h –max-depth-1 find / -type d -size +50M

定时清理磁盘空间： ****** cat /dev/null > /usr/Catalina.out

4. dstat

dstat: 查看网络通畅情况

netstat: 查询tcp连接情况

lsof : 查看tcp网络连接

查询网络连接： netstat -antp | grep ESTABLISHED lsof -I tcp

Tomcat调优

问题：项目在什么时间点介入调优？？（开发之前，测试，线上运行时候）

答案：大多数情况下，项目上线后运行一段时间（持续用户流量，一切问题根源是量的积累，随着用户增多，随着数据量增大，并发的攀升，一段时间，系统出现了问题），此时就必须立马接入调优；

Tomcat配置

1）空闲线程数（最低保活线程数）

2）最大线程数

3）最大连接数（提升连接数）

4）tomcat等待队列（提升队列）

开启20w个样本测试：发现最大线程数为232个，有32个属于tomcat本身自带的线程，200个线程属于业务线程。

问题：tomcat最大线程数为200，是否意味着把线程数提升，服务性能是否一定会提升呢？？

答案：理论上，一定会提升，实际上看接口是否是耗时操作

Tomcat调优配置

server:
  port: 9000
  tomcat:
    min-spare-threads: 10
    max-connections: 10000
    max-threads: 800
    accept-count: 1000
    uri-encoding: UTF-8

把优化后配置进行部署，观察得到的线程数量为800，确实对增大了线程数量：

优化后的tps，经过tomcat调优后，发现tps吞吐能力提升了4倍。

JVM调优

Jvm调优本质：对内存的调优（使用较少内存资源，获取最大的性能），及时释放内存空间垃圾对象；

典型参数

服务器：4cpus , 8GB ，目前来说jvm调优和cpu没有关系，跟内存有关系，因此jvm调优就是调内存：

1、-Xmx4000m 设置堆内存大小（一般情况下，设置物理内存一半即可-经验值设置-如果你想要更加精确的设置，根据程序在压力测试情况下反馈，做出合理的调试；或是通过线上运行项目的反馈情况，进行合理的调试，不同项目，不同业务场景，调试的目标是不一样的）

2、-Xms4000m 设置堆内存初始化大小，必须和mx设置一致，防止内存抖动，从而损耗性能。

3、-Xmn2g 设置年轻代大小（eden,s0,s1）

4、-Xss256k 设置线程堆栈大小，jdk1.5线程堆栈大小默认1MB, 相同内存空间，堆栈越小，操作系统就会创建更多的线程，从而提升性能

JVM在进行gc的时候，通过一些参数打印gc日志，记录gc详细过程情况，以便于分析gc参数设置是否合理，然后对gc参数做出及时更改调试；gc日志可以通过可视化的工具分析（gceasy.io）分析即可。

-XX:+PrintGCDetails : 打印gc详细信息

-XX:+PrintGCTimeStamps : 打印gc时间信息

-XX:+PrintGCDateStamp：打印gc日期信息

-XX:+PrintHeapAtGC : 打印gc堆内存信息

Jvm参数设置，添加到启动脚本即可：

nohup java -Xmx4000m -Xms4000m -Xmn2g -Xss256k -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log  -jar jshop.jar --spring.addition-location=application.yaml > jshop.log 2>&1 &

压力测试，观察gc日志，反馈gc情况：

压测后，把gc.log文件下载下来传到gceasy.io网站进行分析

gc的次数，时间

调试参数

当前服务器配置：8GB, 在大内存服务器下，产生对象很难快速把内存占满，触发gc, 因此对于大内存服务器来说，原则上来说不需要太多的调优，但是对于高并发，高可用的项目来说，jvm调优还是有必要的；因为防止频繁的gc(minor gc , fullgc 都会使得程序stw , 卡顿)

试验1：把内存调小，产生频繁的gc , stw 卡顿时间将会延长

把内存调小，发现程序卡顿时间变长，变成了560+200=760ms；

小结：

1）频繁young gc , 必然会导致老年代空间对象变多，甚至会频繁fullgc ,oom

2）当生命周期比较短暂的对象比较多的话，建议把年轻代空间设置大一些，当老年代空间对象比较多，建议把老年代空间设置大一些。

试验2：把内存空间调大，不会产生频繁的gc,因此程序运行速度变快，也就是说程序的性能提升了。

思考：为什么会发生fullgc 问题，按照垃圾回收理论（old区域被装满了才会触发fullgc）？

因此根据fullgc触发条件：

1、metaspace 元数据空间发生扩容，就会发生fullgc, 且每扩容一次，发生一次fullgc , 如果需要存储的数据超过maxMetaspace, 发生OOM

2、old memory 内存被占满了，发生fullgc,甚至发生oom;

1）通过gc日志观察metaspace是否发生扩容

通过日志可以发现：元数据库初始化大小19822k

通过gc日志的观察，发现metaspace元数据空间发生了扩容；从19822k –> 21254k （第一次扩容，发生第一次fullgc）

2) 通过命令查询metaspace元数据空间初始化大小

查询命令： java -XX:+PrintFlagsFinal -version | grep MetaspaceSize

发现fullgc的原因后，就去把metaspace元数据空间的大小设置大一些，让其扩容不要发生了：

年轻代，老年代大小比例：改如何去设置？

JVM堆内存大小 = 年轻代内存空间 + 老年代内存空间

调整年轻代大小，或者是调整老年代大小都会对整个gc都会有影响（会影响gc性能：年轻代内存空间设置小了，频繁触发minor gc , gc时间变快–balance）,因此堆内存空间大小比例调试也非常重要的；

Sun（官方推荐设置）：

3（young）: 8(堆内存空间) 强调：此设置是推荐设置，不代表最终设置，具体设置还需要根据你的代码业务场景来进行设置；

举个栗子：

当你的代码局部对象非常多，非常适合在年轻代第一次就全部回收，这样业务场景，应该强调把年轻代空间设置大一些，尽量让对象在年轻代被回收

当你老年代对象较多时候，且发送频繁的fullgc , 建议把老年代空间调大一些，方式fullgc的发生。

推荐设置：

官方推荐设置： eden:s0:s1=8:1:1

设置方式： -XX:SurvivorRatio = 8

GC经典组合

吞吐量优先

并行垃圾回收器组合： Parallel Scavenge + Parallel Old , JDK8默认的垃圾回收器，ps+po充分利用多核心cpu资源，在多个cpu上同时执行gc; 因此把这样垃圾回收器叫做吞吐量优先组合；

显式配置（默认不用配）吞吐量优先垃圾回收器组合：

nohup java -Xmx4000m -Xms4000m -Xmn2g -XX:SurvivorRatio=8 -XX:+UseParallelGC -XX:+UseParallelOldGC -Xss256k -XX:MetaspaceSize=200m  -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log  -jar jshop.jar --spring.addition-location=application.yaml > jshop.log 2>&1 &

响应时间优先

响应时间优先的垃圾回收器组合：ParNew + CMS (业务线程,gc线程交叉执行，降低业务线程停顿时间，从而降低业务卡顿)

nohup java -Xmx4000m -Xms4000m -Xmn2g -XX:SurvivorRatio=8 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xss256k -XX:MetaspaceSize=200m  -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log  -jar jshop.jar --spring.addition-location=application.yaml > jshop.log 2>&1 &

G1

G1 垃圾回收器：一个在逻辑上分代的垃圾回收器，使用方式非常简单，高效： -XX:+UseG1GC

连接池调优

druid:
  #配置初始化大小、最小、最大
  initial-size: 1
  min-idle: 5
  max-active: 10
  max-wait: 1200
  time-between-eviction-runs-millis: 600000
  # 配置一个连接在池中最大空闲时间，单位是毫秒
  min-evictable-idle-time-millis: 300000
  # 设置从连接池获取连接时是否检查连接有效性，true时，每次都检查;false时，不检查
  test-on-borrow: true
  #设置往连接池归还连接时是否检查连接有效性，true时，每次都检查;false时，不检查
  test-on-return: true
  # 设置从连接池获取连接时是否检查连接有效性，true时，如果连接空闲时间超过minEvictableIdleTimeMillis进行检查，否则不检查;false时，不检查
  test-while-idle: true
  # 检验连接是否有效的查询语句。如果数据库Driver支持ping()方法，则优先使用ping()方法进行检查，否则使用validationQuery查询进行检查。(Oracle jdbc Driver目前不支持ping方法)
  validation-query: select 1 from dual
  keep-alive: true
  remove-abandoned: true
  remove-abandoned-timeout: 80
  log-abandoned: true
  #打开PSCache，并且指定每个连接上PSCache的大小，Oracle等支持游标的数据库，打开此开关，会以数量级提升性能，具体查阅PSCache相关资料
  pool-prepared-statements: true
  max-pool-prepared-statement-per-connection-size: 20
  # 配置间隔多久启动一次DestroyThread，对连接池内的连接才进行一次检测，单位是毫秒。
  #检测时:
  #1.如果连接空闲并且超过minIdle以外的连接，如果空闲时间超过minEvictableIdleTimeMillis设置的值则直接物理关闭。
  #2.在minIdle以内的不处理。