瓶颈分析

CMS GC知识

CMS，全称Concurrent Mark and Sweep,用于对年老代进行回收，目标是尽量减少应用的暂停时间，减少full gc发生的机率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代。

一次CMS至少会给Full GC的次数 + 2，因为Full GC的次数是按照老年代GC时stop the world的次数而定的。

我们可以认为Major GC == Full GC，他们是一个概念，就是针对老年代/永久代进行GC。

1. 应用系统负载分析：

服务器负载瓶颈经常表现为，服务器受到的并发压力比较低的情况下，服务器的资源使用率比预期要高，甚至高很多。导致服务器处理能力严重下降，最终有可能导致服务器宕机。实际性能测试工作中，经常会用以下三类资源指标判定是否存在服务器负载瓶颈：

• CPU使用率
• 内存使用率
• Load

一般cup的使用率应低于50%，如果过高有可能程序的算法耗费太多cpu，或者某些代码块进行不合理的占用。Load值尽量保持在cpuS+2 或者cpuS*2，其中cpu和load一般与并发数成正比。

• 内存可以通过2种方式来查看：

1) 当vmstat命令输出的si和so值显示为非0值，则表示剩余可支配的物理内存已经严重不足，需要通过与磁盘交换内容来保持系统的稳定;由于磁盘处理的速度远远小于内存，此时就会出现严重的性能下降;si和so的值越大，表示性能瓶颈越严重。

2) 用工具监控内存的使用情况，如果出现下图的增长趋势（used曲线呈线性增长），有可能系统内存占满的情况：

如果出现内存占用一直上升的趋势，有可能系统一直在创建新的线程，旧的线程没有销毁；或者应用申请了堆外内存，一直没有回收导致内存一直增长。

3）内存分页监控sar -B 5 10

对于java应用来说，过高的GC频率也会在很大程度上降低应用的性能。即使采用了并发收集的策略，GC产生的停顿时间积累起来也是不可忽略的，特别是出现cmsgc失败，导致fullgc时的场景。下面举几个例子进行说明：

1. Cmsgc频率过高，当在一段较短的时间区间内，cmsGC值超出预料的大，那么说明该JAVA应用在处理对象的策略上存在着一些问题，即过多过快地创建了长寿命周期的对象，是需要改进的。或者old区大小分配或者回收比例设置得不合理，导致cms频繁触发，下面看一张gc监控图（蓝色线代表cmsgc）

由图看出：cmsGC非常频繁，后经分析是因为jvm参数-XX:CMSInitiatingOccupancyFraction设置为15，比例太小导致cms比较频繁，这样可以扩大cmsgc占old区的比例，降低cms频率注。

调优后的图如下：

2. fullgc频繁触发

当采用cms并发回收算法，当cmsgc回收失败时会导致fullgc：

由上图可以看出fullgc的耗时非常长，在6~7s左右，这样会严重影响应用的响应时间。经分析是因为cms比例过大，回收频率较慢导致，调优方式：调小cms的回比例，尽早触发cmsgc，避免触发fullgc。调优后回收情况如下

可以看出cmsgc时间缩短了很多,优化后可以大大提高。从上面2个例子看出cms比例不是绝对的，需要根据应用的具体情况来看，比如应用创建的对象存活周期长，且对象较大，可以适当提高cms的回收比例。

3. 疑似内存泄露，先看下图