https://www.cnblogs.com/danqiu/p/6009016.html
Jmeter性能测试-GC相关
1.GC相关
HotSpot虚拟机将其物理上划分为两个–新生代(young generation)和老年代(old generation)。
新生代(Young generation): 绝大多数最新被创建的对象会被分配到这里,由于大部分对象在创建后会很快变得不可到达,所以很多对象被创建在新生代,然后消失。对象从这个区域消失的过程我们称之为”minor GC“。
老年代(Old generation): 对象没有变得不可达,并且从新生代中存活下来,会被拷贝到这里。其所占用的空间要比新生代多。也正由于其相对较大的空间,发生在老年代上的GC要比新生代少得多。对象从老年代中消失的过程,我们称之为”major GC“(或者”full GC“)
图中的持久代( permanent generation )也被称为方法区(method area)。他用来保存类常量以及字符串常量。因此,这个区域不是用来永久的存储那些从老年代存活下来的对象。这个区域也可能发生GC。并且发生在这个区域上的GC事件也会被算为major GC。
新生代是用来保存那些第一次被创建的对象,他可以被分为三个空间
- 一个伊甸园空间(Eden )
- 两个幸存者空间(Survivor )
- 绝大多数刚刚被创建的对象会存放在伊甸园空间。
- 在伊甸园空间执行了第一次GC之后,存活的对象被移动到其中一个幸存者空间。
- 此后,在伊甸园空间执行GC之后,存活的对象会被堆积在同一个幸存者空间。
- 当一个幸存者空间饱和,还在存活的对象会被移动到另一个幸存者空间。之后会清空已经饱和的那个幸存者空间。
- 在以上的步骤中重复几次依然存活的对象,就会被移动到老年代。
jstat 是HotSpot JVM提供的一个监控工具
jstat –gc $<pid$> 1000
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
3008.0 3072.0 0.0 1511.1 343360.0 46383.0 699072.0 283690.2 75392.0 41064.3 2540 18.454 4 1.133 19.588
3008.0 3072.0 0.0 1511.1 343360.0 47530.9 699072.0 283690.2 75392.0 41064.3 2540 18.454 4 1.133 19.588
3008.0 3072.0 0.0 1511.1 343360.0 47793.0 699072.0 283690.2 75392.0 41064.3 2540 18.454 4 1.133 19.588
这些信息很重要,因为它们展示了GC处理到底花费了多少时间。
在这个例子中,YGC 是217而YGCT 是0.928,这样在简单的计算数据平均数后,你可以知道每次新生代的GC大概需要4ms(0.004秒),而full GC的平均时间为33ms。
但是,只看数据平均数经常无法分析出真正的GC问题。这是主要是因为GC操作时间严重的偏差(换句话说,假如两次full GC的时间是 67ms,那么其中的一次full GC可能执行了10ms而另一个可能执行了57ms。)为了更好地检测每次GC处理时间,最好使用 –verbosegc来替代数据平均数。
为什么需要优化GC
或者说的更确切一些,对于基于Java的服务,是否有必要优化GC?应该说,对于所有的基于Java的服务,并不总是需要进行GC优化,但前提是所运行的基于Java的系统,包含了如下参数或行为:
- 已经通过 -Xms 和–Xmx 设置了内存大小
- 包含了 -server 参数
- 系统中没有超时日志等错误日志
换句话说,如果你没有设定内存的大小,并且系统充斥着大量的超时日志时,你就需要在你的系统中进行GC优化了。
但是,你需要时刻铭记一条:GC优化永远是最后一项任务。
我为GC优化归纳了两个目的:
- 一个是将转移到老年代的对象数量降到最少
- 另一个是减少Full GC的执行时间
将转移到老年代的对象数量降到最少
按代的GC机制由Oracle JVM提供,不包括可以在JDK7以及更高版本中使用的G1 GC。换句话说,对象被创建在伊甸园空间,而后转化到幸存者空间,最终剩余的对象被送到老年代。某些比较大的对象会在被创建在伊甸园空间后,直接转移到老 年代空间。老年代空间上的GC处理会新生代花费更多的时间。因此,减少被移到老年代对象的数据可以显著地减少Full GC的频率。减少被移到老年代空间的对象的数量,可能被误解为将对象留在新生代。但是,这是不可能的。取而代之,你可以调整新生代空间的大小。
减少Full GC执行时间
Full GC的执行时间比Minor GC要长很多。因此,如果Full GC花费了太多的时间(超过1秒),一些连接的部分可能会发生超时错误。
- 如果你试图通过消减老年代空间来减少Full GC的执行时间,可能会导致OutOfMemoryError 或者 Full GC执行的次数会增加。
- 与之相反,如果你试图通过增加老年代空间来减少Full GC执行次数,执行时间会增加。
因此,你需要将老年代空间设定为一个“合适”的值。
影响GC性能的参数
正如我们在第二篇文章结尾提到的,不要幻想“某个人设定了GC参数后性能得到极大的提高,我们为什么不和他用一样的参数?”,因为不同的Web服务所创建对象的大小和他们的生命周期都不尽相同。
简单来说,如果一个任务的执行条件是A,B,C,D和E,同样的任务执行条件换为A和B,你会觉得哪个更快?从一般人的直觉来看,在A和B条件下执行的任务会更快。
Java GC参数也是相同的道理,设定一些参数不但没有提高GC执行速度,反而可能导致他更慢。GC优化的最基本原则是将不同的GC参数用于2台或者多台服务器,并进行对比,并将那些被证明提高了性能或者减少了GC执行时间的参数应用于服务器。请谨记这一点。
下面这个表格列出了GC参数中与内存大小相关的,可以影响性能的参数。
表1:GC优化需要考虑的Java参数
定义 | 参数 | 描述 |
堆内存空间 | -Xms | Heap area size when starting JVM 启动JVM时的堆内存空间。 |
-Xmx | Maximum heap area size 堆内存最大限制 | |
新生代空间 | -XX:NewRatio | Ratio of New area and Old area 新生代和老年代的占比 |
-XX:NewSize | New area size 新生代空间 | |
-XX:SurvivorRatio | Ratio ofEdenarea and Survivor area 伊甸园空间和幸存者空间的占比 |
我在进行GC优化时经常使用-Xms,-Xmx和-XX:NewRatio。-Xms和-Xmx是必须的。你如何设定NewRatio 会对GC性能产生十分显著的影响。有些人可能会问如何设定Perm区域的大小?你可以通过-XX:PermSize 和-XX:MaxPermSize参数来设定,
当OutOfMemoryError 错误发生并且是由于Perm空间不足导致时,另一个可能影响GC性能的参数是GC类型。下表列出了所有可选的GC类型(基于JDK6.0)
在分析监控结果后,决定是否进行GC优化
在检查GC状态的过程中,你应该分析监控结果以便决定是否进行GC优化,如果分析结果表明执行GC的时间只有0.1-0.3秒,那你就没必要浪费时间去进行GC优化。但是,如果GC的执行时间是1-3秒,或者超过10秒,GC将势在必行。
但是,如果你已经为Java分配了10GB的内存,并且不能再减少内存大小,你将无法再对GC进行优化。在进行GC优化 之前,你必须想清楚你为什么要分配如此大的内存空间。假如当你分1 GB 或 2 GB内存时出现OutOfMemoryError ,你应该执行堆内存转储(heap dump),并消除隐患。
注意:
堆内存转储是一个用来检查Java内存中的对象和数据的文件。该文件可以通过执行JDK中的jmap命令来创建。在创建文件的过程中,Java程序会暂停,因此不要再系统执行过程中创建该文件。
如果GC执行时间满足下面所有的条件,就意味着无需进行GC优化了。
- Minor GC执行的很快(小于50ms)
- Minor GC执行的并不频繁(大概10秒一次)
- Full GC执行的很快(小于1s)
- Full GC执行的并不频繁(10分钟一次)
上面提到的数字并不是绝对的;他们根据服务状态的不同而有所区别,某些服务可能满足于Full GC每次0.9秒的速度,但另一些可能不是。因此,针对不同的服务设定不同的值以决定是否进行GC优化。
- 设定内存空间大小
下表展示了内存空间大小,GC执行次数以及GC执行时间三者间的关系。
-
- 大内存空间
- 减小GC执行次数
- 增加GC执行时间
- 小内存空间
- 减小GC执行时间
- 增加GC执行次数
- 大内存空间
关于如何设置内存空间的大小,没有唯一的标准答案。如果服务 器资源足够,而且Full GC也可能在1秒内完成,设置为10GB当然可行。。但绝大多数服务器并不是这样,当内存设为10GB时,可能要花费10~30秒来执行Full GC。当然,执行时间会随对象的大小而改变。
鉴于如此,我们应该如何设定内存空间大小呢?一 般来说,我建议为500MB。不过请注意这不是让你将WAS的内存参数设置为–Xms500m 和–Xmx500m。根据优化GC之前的状态,如果 Full GC执行之后内存空间剩余300MB,那么最好将内存设置为1GB(300MB(默认程序占用)+ 500MB(老年代最小空间)+200MB(空闲内存))。也就是说你要为老年代额外设置500MB。因此,如果你有三个执行服务器,内存分别设置为 1GB,1.5GB,2GB,并且检查结果。
理论上来讲,GC执行速度应该遵循1GB> 1.5GB> 2GB,因此1GB执行GC速度最快。但是并不说明1GB空间的Full GC会花费1秒而2GB空间会花费2秒。时间取决于服务器的性能和对象的大小。因此,最佳的方式是建立尽可能多的衡量指标来监控他们。
对于内存空间大小,你应该额外设定NewRatio参数。 NewRatio参数是新生代和老年代空间的比例,即XX:NewRatio=1意味着新生代与老年代之比为1:1。对于1GB来说就是新生代和老年代各 500MB。如果NewRatio为2,意味着新生代老年代之比为1:2,因此该值越大,老年代空间越大,新生代空间越小。
这看似一件不是很重要的事情,但NewRatio参数会显著地影响整个GC的性能。如果新生代空间很小,会用更多的对象被转移到老年代空间,这样导致频繁的Full GC,增加暂停时间。
你可以简单的认为NewRatio 为1是最佳的选择,但是,有时可能设置为2或3更好,我就见过很多这样的例子。
如何最快的完成GC优化?对比性能测试的结果 应该是最快地方法,为每一台服务器设置不同的参数并监控他们的状态,强烈建议至少监控1或2天的数据。但是,当你对GC优化是,你要确保每次执行相同的负 载。并且请求的比率,例如URL都应该是一致的。不过,即便对于专业测试人员要想精确的控制负载也是很难的,并要花费大量的时间准备。因此,相对来说比较 方便和容易的方法是调整才参数,之后花费较长的时间收集结果。
示例1
下面这个例子针对 Service S的优化,对于最近被部署的 Service S,Full GC花费了太长的时间。
请看 jstat –gcutil的执行结果。
1 2 |
|
最左边的Perm 空间对于最初的GC优化不是很重要,这一次YGC参数的值更加有用。
Minor GC和Full GC的平均值如下表所示
表3:Service S的Minor GC 和Full GC的平均执行时间
GC 类型 | GC 执行次数 | GC 执行时间 | 平均 |
Minor GC | 54 | 2.047 | 37 ms |
Full GC | 5 | 6.946 | 1,389 s |
最重要的是下面两个数据
- 新生代实际使用空间: 212,992 KB
- 老年代实际使用空间: 1,884,160 KB
因此,总的内存空间为2GB,不算Perm空间的话,新生代与老年代之比为1:9。通过jstat和-verbosegc 日志进行数据收集,并把三台服务器按照如下方式设置。
- NewRatio=2
- NewRatio=3
- NewRatio=4
一天之后,检查系统的GC日志后发现,在设置了NewRatio参数后很幸运的没有发生Full GC,
为什么?
- NewRatio=2: 45 ms
- NewRatio=3: 34 ms
- NewRatio=4: 30 ms
我们看到NewRatio=4 是最佳的参数,虽然它的新生代空间最小,但GC时间确最短。设定这个参数之后,系统没有执行过Full GC。
为了说明这个问题,下面是服务之星一段时间后执行jstat –gcutil的结果
1 2 |
|
你可能会认为因为服务器接受的请求少才导致的GC执行频率下降。实际上,虽然Full GC没有执行,但是Minor GC被执行了 2,424次。
示例2
这是一个针对ServiceA的例子,我们通过公司内部的应用性能管理系统(APM)发现JVM暂停了相当长的时间(超过8秒),因此我们进行了GC优化。我们找到了Full GC执行时间过长的原因,并着手解决。
进行GC优化的第一步,就是我们添加了-verbosegc参数,并得到如下结果。
图1:进行GC优化之前的STW时间
如上图所示,由HPJMeter自动生成的图片之一。X坐标表示JVM执行的时间。Y坐标表示每次GC的时间。CMS绿点,表示Full GC结果。Parallel Scavenge蓝点,表示Minor GC结果。
之前我曾经说过CMS GC是最快的,但是上面的的结果显示出于某种原因,它最多花费了15秒。是什么导致这个结果?是否想起我之前提过的,CMS在进行内存清理时,会变慢。与此同时,服务的内存被设定为 –Xms1g和–Xmx4g ,且实际分配了4GB内存。
因此,我将GC类型从CMS改为Parallel GC。并且将内存改为2GB,设定NewRatio 为3。几小时之后我使用 jstat –gcutil得到如下结果
1 2 |
|
相对于4GB时的15秒,Full GC变成了平均每次3秒。但是3秒一样比较慢,因此我设计了如下6种场景。
- Case 1: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=2
- Case 2: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=3
- Case 3: -XX:+UseParallelGC -Xms1g -Xmx1g -XX:NewRatio=3
- Case 4: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=2
- Case 5: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=3
- Case 6: -XX:+UseParallelOldGC -Xms1g -Xmx1g -XX:NewRatio=3
那一个最快呢?结果显示,内存越小,结果越好。下图展示了Case6的结果。这是GC的性能最好。最长的响应时间只有1.7秒。平均时间在1秒之内。
图2:Case6的时间图表
基于以上结果。我们按照Case6调整了GC参数。但是,这导致了每天晚上都会发生OutOfMemoryError。在这里很难解释具体的原因。简单来说,批处理程序导致了内存泄漏。相关的问题已经被解决。
如果对GC日志只分析很短的时间就贸然对所有服务器进行优化是非常危险的。请时刻牢记,你必须同时分析GC日志和应用程序。
我们回顾了两个关于GC优化的例子,正如我之前提到的,例子中提到的GC参数,可以设置在相同的服务器之上,但前提是他们具有相同的CPU,操作系统,JDK版本以及运行着相同的服务。但是不要直接把我用过的参数用到你的服务至上,它们未必能很好的工作。
切实地调优
如果测试的结果满足了预期,那么你不需要对程序进行性能调优。如果没有达到预期结果,你就应该执行调优来解决问题。接下来会通过实例讲解方法。
stop-the-world耗时过长
stop-the-world耗时过长可能是由于GC参数不合理或者代码实现不正确。你可以通过分析工具或堆内存转储文件(Heap dump)来定位问题,比如检查堆内存中对象的类型和数量。如果在其中找到了很多不必要的对象,那么最好去改进代码。如果没有发现创建对象的过程中有特别 的问题,那么最好单纯地修改GC参数。
为了适当地调整GC参数,你需要获取一段足够长时间的GC日志,还必须知道哪些情况会导致长时间的stop-the-world。想了解更多关于如何选择合适的GC参数,可以阅读我同事的一篇博文:How to Monitor Java Garbage Collection。
CPU使用率过低
当系统发生阻塞,吞吐量和CPU使用率都会降低。这可能是由于网络系统或者并发的问题。为了解决这个问题,你可以分析线程转储信息(Thread dump)或者使用分析工具。阅读这篇文章可以获得更多关于线程转储分析的知识:How to Analyze Java Thread Dumps。
你可以使用商业的分析工具对线程锁进行精确的分析,不过大部分时候,只需使用JVisualVM中的CPU分析器,就能获得足够的信息。
CPU使用率过高
如果吞吐量很低但是CPU使用率却很高,很可能是低效率代码导致的。这种情况下,你应该使用分析工具定位代码中性能的瓶颈。可使用的工具有:JVisualVM、Eclipse TPTP或者JProbe。
调优方法
建议你使用如下方法对程序进行调优。
首先,检查性能调优是否必要。测量性能不是一件简单的工作,你也不能保证每次都获得满意的结果。因此如果程序已经满足预期性能需求,不必在调优上增加额外的投入了。
问题只出在一个地方,你要做的就是去解决掉它。二八定律(Pareto principle)对性能调优同样适用。这不是说某个模块的低性能一定只源于一个问题,而是强调我们应该在调优时把注意力放在影响最大的那个问题上。在处理好了最重要的之后,你才应该去解决剩下其他的。也就是建议一次只对一个问题进行修复。
另外需要考虑到气球效应(Balloon effect),有得必有失。你可以通过使用缓存来提高响应能力,但是当缓存逐渐增大,执行一次Full GC的时间也会更长。一般而言,如果你希望内存使用率比较低,那么吞吐量和响应能力可能都会恶化。因此,要知道什么对自己程序来说最重要的,而哪些又是次要的。
到此为止,你应该已经了解了如何对Java程序进行性能调优。为了介绍性能测定的具体过程,我不得不省略其中一些细节,不过我认为这些也足够应对大多数Java Web服务端程序了
2.操作相关
1.如何考虑一个性能需求
1. 通常拿到一个性能需求,需要了解接口模型,整个接口的使用比例和容量,系统结构和技术方案,数据库缓存和索引分布,设计出合理的测试计划,设计的原则是尽可能真实的模拟线上情况。
2.根据设计出的测试计划,使用一个线程运行测试计划,得出测试结果,对比测试指标
3.以线性增长的方式增加并发数,比较测试结果是否为线性增长
4.测试结果平缓区通常代表着系统容量的最大区域,分析此时的测试结果,如 TPS和响应时间等
5.分析数据库TPS、QPS等数据,redis命中率,MQ吞吐率,javaGC,程序占用时间等各方面因素提高系统性能
6.通过jstack分析各模块的资源占用情况。
7.优化后的程序要经过大批量数据测试确保测试程序不会发生错误
8.根据测试概要报告,数据库监控数据等数据整合测试报告
9. 需要关注api层用的是长连接还是短连接,长连接的话需要在jmeter里勾选keep alive
2.如何保证jmeter自身性能
1.使用命令行启动,减少界面造成的性能问题
2.命令行记录聚合报告,不要启动过多的其他监控报告
3.尽可能关闭不必要的日志,包括测试代码的log,jmeter自身日志。
4.确保测试脚本计时准确,需确认好那些步骤需要计时,那些在准备在计时之外
5.过多的并发使用分布式请求,当本地cpu,mem占用比较大时,修改jmeter.properties,增加远程remote-server,并启动(具体操作见jmeter操作手册)
3.如何分析测试结果
1.根据聚合报告分析90%,95%,和最大等指标,找出程序普遍的响应时间。
2.让开发人员查询最大响应时间时的日志,分析程序层面的执行任务情况
3.使用jstack等分析当前程序的资源等待情况,系统资源情况
值得关注的线程状态有:
死锁,Deadlock(重点关注)
执行中,Runnable
等待资源,Waiting on condition(重点关注)
等待获取监视器,Waiting on monitor entry(重点关注)
暂停,Suspended
对象等待中,Object.wait() 或 TIMED_WAITING
阻塞,Blocked(重点关注)
停止,Parked
示例图
4.分析gc结果,cpu,IO等情况,分析程序是否充分利用了系统资源
5.对比分析各并发数的程序响应情况。
分类: 性能测试