性能测试实战分享2---full GC 过多

场景和现象说明：

1、观察数据库服务器，cpu使用率在11%左右，看oracle的awr日志，没看到特别慢的sql（有三条sql加起来耗时不到一百毫秒）

2、应用服务器，有几台cpu使用率70%左右（几台都是同功能的），频繁fullgc，用的是cms，设置了到70%就回收。堆内存5千兆。

这接口慢应该怎么分析。可以通过看日志分析哪里慢吗？

问题：接口平均响应时间比较慢，约1.63秒；

监控现象：

1、full GC频繁；

2、应用服务器CPU占比70%左右，略高；

3、磁盘写较大，超15MB；

初步原因分析：SQL返回大量数据导致（数据库返回某个字段有1M多数据），正常一个字段不可能有1M多的内容，基本都是几KB，超百KB都会优化的，根本需要优化这个字段的数据返回；

解决方案：根本需要优化这个字段的数据返回；临时解决方案：该返回字段使用键值对，对应使用Redis缓存储存数据；

分析思路：

第一步：分析客户端和服务端的性能，看是否有性能瓶颈（CPU，内存，磁盘，网络）；

第二步：分析磁盘读/写是否较大

第三步：发现磁盘过大，最后分析是不是因为数据库读/写过大导致；

本次测试的经验分享：

1、通过jemter-permon监控分析服务端的硬件性能，看是否有性能瓶颈（CPU，内存，磁盘，网络），结果：发现磁盘写的大，写的大小有15MB；队列等待也有增长，await 大于 svctm约16毫秒，说明 I/O等待时长有点 小高

2、数据库SQL返回大量数据（数据库返回某个字段有1M多数据），正常一个字段不可能有1M多的内容，基本都是几KB，超百KB都会优化的，根本需要优化这个字段的数据返回；

问题监控现象图：