JAVA程序性能调优(一)

性能调优

官网理论：

https://docs.oracle.com/cd/E19900-01/819-4742/abeik/index.html
heap size xms=G1 eden space+G1 survivor space+ G1 old Gen space
newRatio=old gen/new gen
New gen= xmx/(1+newRatio)
The default NewRatio for the Server JVM is 2
故：New gen=xmx/3

配置推荐：

keep the eden size between one fourth and one third the maximum heap size.
each survivor space will be one eighth of the young generation.
keep heap size will be one half RAM memory

实验验证

背景，作为CI/CDteam ，为了解决性能测试环境部署复杂的问题，通过容器化思想一键部署环境，但基于k8s cluster部署的site 比搭建在物理ec2机器上的site，性能较差一些，压测时错误率更大些。分析探查原因。
1）物理site: url： https://clone-uconn-perf-test1.blackboard.com/
监控信息https://rpm.newrelic.com/accounts/672423/applications/61159309/instances


newrelic 关键字：cloud-learn-clone-uconn-perf-test1
由site url在captain上查找对应的aws的EC2机器ip信息，
然后ssh，查看进程、memory、disk等信息

emambp:learn ema$ ssh us+ipema@ip:~$ ps -ef|grep java bbuser    4110  2771  8 Nov20 ?        1-08:11:43 /usr/lib/jvm/java-8-oracle-amd64/bin/java -d64 -server -Dblackboard.wrapper.anchorfile=/usr/local/blackboard/apps/tomcat/work/tomcat.anchor -Dblackboard.wrapper.commandfile=/usr/local/blackboard/apps/tomcat/work/wrapper.command -Xss400k -Djava.io.tmpdir=/usr/local/blackboard/apps/tomcat/temp -Djava.security.manager -Djava.security.policy==/usr/local/blackboard/apps/tomcat/conf/catalina.policy -Djava.util.logging.config.file=/usr/local/blackboard/config/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dfile.encoding=UTF-8 -Dcatalina.home=/usr/local/blackboard/apps/tomcat -Dcatalina.base=/usr/local/blackboard/apps/tomcat -Dblackboard.home=/usr/local/blackboard -Dblackboard.shared.home=/usr/local/bbcontent -Dbbservices_config=/usr/local/blackboard/config/service-config.properties -Djava.awt.headless=true -Dcom.sun.management.jmxremote -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/blackboard/logs/tomcat -Xloggc:/usr/local/blackboard/logs/tomcat/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:ReservedCodeCacheSize=128m -XX:InitialCodeCacheSize=16m -javaagent:/usr/local/blackboard/apps/newrelic/lib/newrelic.jar -javaagent:/usr/local/blackboard/apps/jolokia/lib/jolokia.jar -Dcom.sun.management.jmxremote.port=8899 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Duser.timezone=US/Eastern -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1536m -Djava.util.prefs.userRoot=/home/bbuser -Djava.util.prefs.systemRoot=/home/bbuser/.java -XX:+CMSClassUnloadingEnabled -Dsun.net.inetaddr.ttl=60 -Djava.net.preferIPv4Stack=true -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=45 -XX:+UseStringDeduplication -Dsun.net.maxDatagramSockets=512 -XX:StringTableSize=200003 -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 -Dsun.net.client.defaultConnectTimeout=30000 -Dsun.net.client.defaultReadTimeout=30000 -Dorg.apache.activemq.SERIALIZABLE_PACKAGES=java.lang,java.util,org.apache.activemq,org.fusesource.hawtbuf,com.thoughtworks.xstream.mapper,net.sf.ehcache.distribution -Xms8704M -Xmx8704M -Djava.library.path=/usr/local/blackboard/apps/service-wrapper/lib:/usr/local/blackboard/apps/tomcat/lib:/usr/local/blackboard/apps/exec/lib:/usr/local/blackboard/apps/oracle-client/lib64:/usr/local/blackboard/apps/sigar/lib -classpath /usr/local/blackboard/apps/service-wrapper/lib/wrapper.jar:/usr/lib/jvm/java-8-oracle-amd64/lib/tools.jar:/usr/local/blackboard/apps/tomcat/lib/bb-tomcat-bootstrap.jar:/usr/local/blackboard/apps/tomcat/bin/bootstrap.jar:/usr/local/blackboard/apps/tomcat/bin/tomcat-juli.jar -Dwrapper.key=7k9Tv6HXEC33LKVV -Dwrapper.port=32001 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=2771 -Dwrapper.version=3.2.3 -Dwrapper.native_library=wrapper.64 -Dwrapper.service=TRUE -Dwrapper.disable_shutdown_hook=TRUE -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=2 org.tanukisoftware.wrapper.WrapperStartStopApp blackboard.tomcat.startup.ThreadDumpWrapper 1 start blackboard.tomcat.startup.ThreadDumpWrapper true 1 stop

配置如下：
tomcat配置参数heapsize：-Xms8704M -Xmx8704M 8G
登录物理机器看到top：
KiB Mem : 16431212 total, 900800 free, 11743668 used, 3786744 buff/cache

实验操作：5/24 开始导数据 10月23-25压测

10.23 下午10：30-11：30 NewRelic收集数据（1）

Tables Max Committed Used G1 old Gen heap usage(MB) 8700 7500 2730 G1 Eden space heap usage(MB) 0 1120 496 G1 Survivor Space heap usage(MB) 0 80 80 Heap memory usage(MB) 8700 8700 3306

committed： old Gen：new Gen =6.25
used： old Gen：new Gen =4.7
压测期间gc峰值，
G1 young generation garbage collection 4%
G1 old generation garbage collection 23%
调优：通过NewRatio控制新生代老生代比例
2）
https://rpm.newrelic.com/accounts/672423/applications/71461475?tw%5Bend%5D=1508884995&tw%5Bstart%5D=1508861104

3）为了解决测试环境部署复杂的问题，通过容器化思想一键部署环境site on k8s
监控信息https://rpm.newrelic.com/accounts/672423/applications/107275816/instances


配置如下：
tomcat 启动参数配置-Xms 2048M -Xmx 2048M
yml文件部署deployment的时候，request memory参数 10240M= 10G

12.5 下午4：00-6：00 压测，前面一段时间导数据
15：30-15：31 导数据阶段 数据（2）

Tables Max Committed Used G1 old Gen heap usage(MB) 2050 1330 300 G1 Eden space heap usage(MB) 0 682 621 G1 Survivor Space heap usage(MB) 0 36.3 36.3 Heap memory usage(MB) 2050 2048.3 957.3 GC-G1 Young generation 2.31%

committed： old Gen：new Gen =1.7

17：34-17：35 压测末期 数据（3）

Tables Max Committed Used G1 old Gen heap usage(MB) 2050 1910 1540 G1 Eden space heap usage(MB) 0 125 50.3 G1 Survivor Space heap usage(MB) 0 14.9 14.9 Heap memory usage(MB) 2050 2049.9 1605.2 GC-G1 Young generation 31.5%

committed： old Gen：new Gen =13.6
used： old Gen：new Gen =23.6

三组数据，验证发现如下结论：

1. heap size xms=G1 eden space+G1 survivor space+ G1 old Gen space
2. 对比数据（2）（3），发现压测时，gc 从2.31%飙到31.5% 对比正常的物理site，只有4%左右的gc，明显不正常。
   分析–
   为什么会耗费大量cpu时间做gc 说明heapsize设置的较小，压测的case会大量创建object or function等等，heapsize马上被耗费完，则需要gc。所以查看对比 真实site的 heapsize的设置，发现确实比较小（2048M 对比 8704M） 。因为压测是同一批case。
   调优实例1：
   调整物理memory ：16G
   -xms 8792M xmx 8792M
3. 对比数据（1）（3），发现committed/used的old Gen heap usage与Eden space heap usage+G1 Survivor Space heap usage=G1 New Gen heap usage 的比例不等于 官网推荐的默认值2，都远远大于2。说明分配的比例不太合适。但奇怪的是查找源代码中没有发现关于

-XX:NewRatio=ratio-XX:NewSize=size-XX:MaxNewSize=size

的相关配置。疑问点？？？
调优实例2：
新老生代的比例 这个直接影响 minor gc 和full gc占用cpu的时间。且理论上，full gc比minor gc会更slow ，更耗时些。性能测试时，full gc 不能过高，否则影响溪能测试的效果。JVM参数NewRatio 可能需要调整。

题外话：

监控工具newrelic 中，apm -jvm 页面的数据信息（关于GC / Old space /eden space等信息）个人猜测应该来源于jstat。实时采集然后实时绘制。
Jstat是JDK自带的一个轻量级小工具。
命令格式
jstat命令命令格式：
jstat [Options] vmid [interval] [count]
参数说明：
Options，选项，我们一般使用 -gcutil 查看gc情况
vmid，VM的进程号，即当前运行的java进程号
interval，间隔时间，单位为秒或者毫秒
count，打印次数，如果缺省则打印无数次
示例说明
示例
通常运行命令如下：

jstat -gc 4110 5000即会每5秒一次显示进程号为4110的java进成的GC情况也可 输出到log文件，jstat -gc 4110 5000 >gc.log

ema@ip:~$ sudo  jstat -gc 4110  S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT 0.0   65536.0  0.0   65536.0 667648.0 139264.0 8179712.0  2813164.3  641080.0 622188.4 84112.0 80447.9  21688 4787.188   0      0.000 4787.188

---

参考：
http://www.cnblogs.com/zhguang/p/Java-JVM-GC.html
https://www.journaldev.com/2856/java-jvm-memory-model-memory-management-in-java
https://docs.oracle.com/cd/E19900-01/819-4742/abeik/index.html
https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/memman.html