Common JVM tuning commands
JPS — View the PID corresponding to the program
[root@ams_cms01 tes]# jps
25841 Starter
26691 jar
13332 jar
20134 BrokerStartup
6361 jar
18668 NamesrvStartup
Copy the codeJMAP – Finds thread memory usage
JMAP prints the number of class instances and the amount of memory within the thread
// You can view the number of instances and the amount of memory in the thread jmap-histo 13332Copy the code num #instances #bytes class name
----------------------------------------------
1: 15760 47434048 [B
2: 161343 21937496 [C
3: 48290 7713600 [Ljava.lang.Object;
4: 140621 3374904 java.lang.String
5: 29745 2617560 java.lang.reflect.Method
6: 11216 1876680 [I
7: 2418 1586208 io.netty.util.internal.shaded.org.jctools.queues.MpscArrayQueue
8: 14127 1571504 java.lang.Class
9: 47662 1525184 java.util.concurrent.ConcurrentHashMap$Node
10: 27057 1103008 [Ljava.lang.String;
11: 31809 1017888 java.lang.ref.WeakReference
Copy the codeJMAP prints stack information
jmap -heap 13332
Copy the codeAttaching to process ID 13332, please wait... Server Compiler detected. JVM version is 25.172-B11 using thread-local object allocation. Parallel GC with 13 thread(s) Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 268435456 (256.0MB) NewSize = 44564480 (42.5MB) MaxNewSize = 89128960 (85.0mb) OldSize = 89653248 (85.5MB) NewRatio = 2 SurvivorRatio = 8 MetaspaceSize = 21807104 (20.796875MB) CompressedClassSpaceSize = 1073741824 (1024.0MB) MaxMetaspaceSize = 17592186044415 MB G1HeapRegionSize = 0 (0.0MB) Heap Usage: PS Young Generation Eden Space: Capacity = 41418752 (39.5MB) Used = 15461184 (14.74493408203125MB) Free = 25957568 (24.75506591796875MB) 37.32894704311709%, informs the From Space: Capacity = 1572864 (1.5MB) Used = 700480 (0.66802978515625MB) Free = 872384 (0.83197021484375MB) 44.535319010416664% used To Space: Capacity = 1572864 (1.5MB) Used = 0 (0.0MB) Free = 1572864 (1.5MB) 0.0% Used PS Old Generation Capacity = 133169152 (127.0MB) Used = 109122936 (104.06774139404297MB) Free = 24046216 (22.93225860595703MB) 81.94310345987635% UsedCopy the codeJstack — Check the thread status
jstack 13332
Copy the code"DubboServerHandler-172.10.0.7:28999-thread-79" #539 daemon prio=5 OS_PRIo =0 tid= 0x00007eff2C05e000 nid=0x1164 waiting on condition [0x00007efe3b9f8000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f25f76b8> (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362) at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:924) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) "DubboServerHandler-172.10.0.7:28999-thread-78" #534 daemon prio=5 OS_PRIo =0 tid= 0x00007eff2C05d000 nid=0x939 waiting on condition [0x00007efe3bbfa000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f25f76b8> (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362) at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:924) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)Copy the codeJSTAT — Tuning focus: check GC status
// Monitor thread with PID = 13332, print once every second, print 10 times jstat -gc 13332 1000 10Copy the code S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
1536.0 1536.0 448.0 0.0 40448.0 5105.7 130048.0 106565.4 79664.0 75844.2 9776.0 9048.1 4082 33.338 248 31.693 65.032
1536.0 1536.0 448.0 0.0 40448.0 5109.8 130048.0 106565.4 79664.0 75844.2 9776.0 9048.1 4082 33.338 248 31.693 65.032
1536.0 1536.0 448.0 0.0 40448.0 5225.4 130048.0 106565.4 79664.0 75844.2 9776.0 9048.1 4082 33.338 248 31.693 65.032
1536.0 1536.0 448.0 0.0 40448.0 5225.4 130048.0 106565.4 79664.0 75844.2 9776.0 9048.1 4082 33.338 248 31.693 65.032
Copy the codeField meaning
S0C: size of the first survival area, unit KB S1C: size of the second survival area S0U: size of the first survival area S1U: size of the second survival area EC: size of Eden Park EU: size of Eden Park OC: Old age size OU: size of old age MC: Method area size (meta-space) MU: method area size CCSC: compressed class space size CCSU: compressed class space size YGC: number of garbage collection times of the young generation YGCT: number of garbage collection times of the young generation (unit: s) FGC: number of garbage collection times of the old generation FGCT: GCT: Total time spent in garbage collection (unit: s)Copy the codeUse scenarios for invoking commands
JMAP
If an application has a memory problem, such as on the OOM, you can use JMAP to analyze the problem
Jstack
When the application has a thread problem such as deadlock, you can use the
Optimization analysis of line up-regulation
A new project came online last month, and there didn’t seem to be any alarms. When I looked at the running of the production environment today, I found that the application had performed nearly 250 Full GCS. It happens once every 3 hours on average! emmm…. Fortunately, no one has complained yet.
Jmap-heap view program memory:
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 268435456 (256.0MB)
NewSize = 44564480 (42.5MB)
MaxNewSize = 89128960 (85.0MB)
OldSize = 89653248 (85.5MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)
Copy the code
Small head, big question, why only 256M heap memory? !
The JSTAT -gc command shows that at the peak of the day, 20M objects are generated every minute on average, and the Eden zone is occupied in 2-3 minutes. Minor GC is triggered, and 8M or so of the alive objects are moved to the Survivor zone (2 x 15M). In the next Minor GC, the dynamic age of objects is determined and the number of objects generated in the last Minor GC exceeds 50% of the S1 region. In this case, the objects that survived in the last Minor GC are directly moved to the old age (100M). Therefore, in the peak period, the old generation will be occupied within 30 minutes and carry out a Full GC.
Therefore, from the above analysis, there are two reasons for frequent APPLICATION GC:
- The heap is too small.
- Dynamic age determination of objects, resulting in objects being prematurely placed in the old age.
Solution:
- Expand the heap memory size: -xMS 1024M -xmx 1024M
- Since the objects in the application are basically ephemeral, there is not much need for the old generation, so change the ratio of the new generation to the old generation/or increase the size of the Big Generation: -xx :NewRatio=1 / -xmn600m