Basic course three JVM: JVM Tuning

JVM Tuning

1. JVM mainly allocated memory size setting, selection and garbage collector configuration parameter adjustment to the number of GC and GC to control time, the purpose of improving the response time and throughput applications;

JVM Monitoring

1. JVM monitoring tools are: jps, jstat, jinfo, jmap, jhat, jconsole, virtualVM, linux may need to go to the bin directory and execute with ./;

2. jps, jinfo parameters for analysis of the promoter, jstat, jmap analysis for real-time situation, jconsole, virtualVM to visual analysis;

JPS

1. jps -l -v to view all jvm process, will show "pid jar package jvm parameters" and other information, it can be easily used to view the application starts, this can also be very easy to check whether the application startup script to take effect;

JSTAT

1. jstat -class pid pid process used to view the current class load case;

加载11975个类，占据21KB
Loaded  Bytes  Unloaded     Bytes     Time   
11975   21647.2        0     0.0       8.99

2. jstat -gcutil pid to view jvm memory usage (percent);

S0使用0%，S1使用34%，E使用32%，O使用31%，M使用95%，YGC 19次，总共0.21s，FGC3次，总共0.5s，gc总共0.75s
S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
0.00  34.04  32.72   31.37  95.65  93.51    19    0.210     3    0.548    0.758

3. jstat -gc pid jvm used to view memory usage, real specific value;

4. Even more parameters, with particular reference to: https: //www.cnblogs.com/yjd_hycf_space/p/7755633.html

JINFO

1. jinfo pid is used to view the actual start jvm parameters, can be used to verify whether the startup script into force, with particular reference to: https: //www.jianshu.com/p/8d8aef212b25

JMAP

1. jmap -heap pid, view heap usage;

2. jmap -histo 29620> log.txt, see the pid 29620 application, the heap memory in the number and size of data to export the object instance to the log.txt;

3. jmap -dump: format = b, file = heapdump.hprof 19287, export dump file is currently heap memory mirroring, dump files can be used virtualvm, mat and other tools to analyze, the command will suspend the application, production environment with caution;

VirtualVM and MAT

1. virtualVm dump file can be analyzed, or analyzed using real-time memory is connected via a remote JMX application;

2. mat, but also a heap analysis tool dump file, you can view the instance size, the number of occupied space (deep stack, shallow heap);

JSTACK

1. jstack (-F) pid Print this process all the thread stack information, equivalent to Thread.getAllStackTraces (), is used to detect deadlocks and thread consumption detect cpu too high.

Jःat

1. jhat also be used to analyze the dump file, generate html page analysis

JVM monitoring demonstration

1. View the current linux machine environment

top -c
Cpu(s):  6.9%us,  1.5%sy,  0.0%ni, 91.5%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8062128k total,  7820904k used,   241224k free,   151844k buffers
// 通过top命令来查看机器的cpu和内存使用率，91.5id，表示CPU未使用率。内存241M的空闲，另外可以查看到进程的cpu和内存使用情况
df -h
Filesystem            								Size  Used 	Avail 		Use% 		Mounted on
/dev/mapper/vg_root-lv_root				78G   74G   16M 		100% 		/
tmpfs                 									3.9G     0  	3.9G   		0% 			/dev/shm
/dev/sda1             								477M   40M  413M  	 9% 			/boot
/dev/mapper/vg_root-lv_home			13G     203M   12G   		2% 		/home

2. View the current application memory allocation settings

jps -l -v
15143 cu-ibas-pay-provider.jar -Dlog4j.path=/app/applogs/ibasPre

ps -ef|grep cu-ibas-pay-provider.jar 
qzd      15143     1  0 Jan20 ?        00:25:07 java -jar -Dlog4j.path=/app/applogs/ibasPre cu-ibas-pay-provider.jar -Xms768m -Xmx768m -Xss256K -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 
// 通过jps发现启动只有一个参数设置，进一步通过ps发现，启动命令有问题，cu-ibas-pay-provider.jar 之后全部不生效，通过修改发现生效

jinfo 15143
Non-default VM flags: -XX:CICompilerCount=3 -XX:InitialHeapSize=130023424 -XX:MaxHeapSize=2065694720 -XX:MaxNewSize=688390144 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=42991616 -XX:OldSize=87031808 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC 
Command line:  -Dlog4j.path=/app/applogs/ibasPre
// 通过jps，发现内存设置是初始堆124M，最大堆1.9G，新生代最大656M，初始新生代41M，老年代83M，使用的ParallelGC

jstat -class 15143
Loaded  Bytes  Unloaded  Bytes     Time   
 19617 36120.2        0     0.0     162.67
// 通过jstat，发现162ms，载入19617个类，共36M

3. Memory real-time monitoring applications, GC situation

jstat -gc 15143
 S0C      S1C       S0U       S1U      EC       EU               OC         OU                MC     MU           CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
11264.0 16384.0 10857.0  0.0   411648.0 133948.3  185856.0   75930.1   112920.0 108128.9 14104.0 13258.3     38   27.725   4      1.045   28.770
// 通过jstat，发现当前 S0分配11M，使用10M，S1分配16M，使用0，Eden分配411M，使用133M，Old分配185M，使用75M，Metaspace分配112M，使用108M，minorGC 38次，fullGC4次，

jmap -heap 15143
// 比jstat更直观，但没有gc信息

4. Memory monitoring actuator springboot applications

5. Heap dump file analysis

jmap -dump:format=b,file=[filename][pid]，gceasy（在线https://gceasy.io/），GCViewer

GC log analysis

1. GC logs need to specify the startup parameters of the application, as specified GC log generation directory, specify the GC log generation formats, the current dump file is generated when the specified heap overflow

//	设置在应用日志中输出gc详细信息
-verbose:gc 
//  设置日志中打印GC详情，和-verbose:gc类似													
-XX:+PrintGCDetails
//  设置日志中打印GC时间戳											
-XX:+PrintGCTimeStamps 		
//  设置单独生成gc日志文件							
-Xloggc:[file]      
//  设置堆溢出时导出dump    													
--XX:+HeapDumpOnOutOfMemoryError  	
// 	设置堆dump溢出文件路径				
-XX:HeapDumpPath=/applogs/pre-yg-web_heapdump 	
// 设置jvm崩溃时的日志文件路径
-XX:ErrorFile=[file]															

2. Focus GC log: pause time and throughput accounted for, such as:

// 新生代无法分配内存空间，触发Minorgc，新生代从31744K回收到2647K，新生代总空间36844K，整个堆从31744K回收到2655K，堆的总大小121856K，耗
// 时；
0.448: [GC (Allocation Failure) [PSYoungGen: 31744K->2647K(36864K)] 31744K->2655K(121856K), 0.0086293 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
1.938: [GC (Metadata GC Threshold) [PSYoungGen: 210895K->3950K(259072K)] 214127K->8630K(344064K), 0.0073356 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]
// Metadata元数据区达到阈值，触发FullGC，新生代从3959K回收到0K，总大小259072K，老年代从4679K会受到8046K，堆总大小从8630K回收到8046K，堆
// 总大小314880K，元数据区从20699K会受到20699K，元数据区总大小1067008K。
1.946: [Full GC (Metadata GC Threshold) [PSYoungGen: 3950K->0K(259072K)] [ParOldGen: 4679K->8046K(55808K)] 8630K->8046K(314880K), [Metaspace: 20699K->20699K(1067008K)], 0.0481115 secs] [Times: user=0.14 sys=0.00, real=0.05 secs] 

common problem

1. Common causes of JVM memory leak:
   large static objects, static objects will only clean up FullGC, and will not be recovered when the class is still in use, causing memory has been occupied;
   frequent String of the + operator, as frequently create new String objects, you can use StringBuilder or StringBuffer in place, but the new version of jdk has been optimized;
   create objects cycle, the level of recursion depth can also cause memory leaks, try to create outside the loop, object-multiplexing, object pooling, control object scope, do not have too much method.

2. java application startup script

java -jar -Dlog4j.path=/applogs pre-web.jar & -Xloggc:/applogs/pre-web_gc.log
// 上面这样写是绝对错误的，会导致后面的设置不生效，需要改为
java -jar -Dlog4j.path=/applogs -Xloggc:/applogs/pre-web_gc.log pre-web.jar &
// 可以通过jps -l -v，jinfo pid来验证

3. Identify high proportion of cpu thread

// 找到cpu占比高的进程的pid
top -c 
// 得到进程中的线程tid 
ps -mp <pid> -o THREAD,tid,time | sort -k2r
// 将tid转16进制，并得到线程的堆栈信息
jstack -l <pid> | grep <thread-hex-id> -A 10 

4. Deadlock Detection

jstack -F pid来检测

5. To reduce the number of FullGC, the most important thing is to ensure stability, using scopes and other old age means to ensure timely objects to be recycled instead of being moved to the old era. At the same time try to avoid using large objects (because of a security mechanism into the old s), use the appropriate data structure: long type: 8byte, while Long type: 24byte;