The JVM in full

OOM case

Stack overflow

• VisualVM analyzes dump files
• Locate the location that caused the error

• Find a mass generated object

• Mat analysis
• Find the leak suspect

• Thread information

• Storing a large number of objects

• ErgonomicsAdaptive adjustment caused by

• GCEasy looks at the GC effect

why

• There may be large object allocation
• There may be a memory leak that prevents you from finding a large chunk of memory to hold the current object after multiple GC’s

The solution

• Check the allocation of large objects
• Dump file
• use-XmxIncrease memory
• Whether there is a lot of customizationFinalizableObject, provided internally by the framework

Metaspace removal

• parameter

-XX:+PrintGCDetails
-XX:MetaspaceSize=60m
-XX:MaxMetaspaceSize=60m
-Xss512K
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=heap/heapdump4.hprof
-XX:SurvivorRatio=8
-XX:+PrintGCDateStamps
-XX:+TraceClassLoading
-XX:+TraceClassUnloading
-Xms50M
-Xmx50M
-Xloggc:log/gc-oom4.log
Copy the code

• visualVM

• jstat -gc idViewing GC

YGC count YGCT Time Total GCT time

• The error code

• The MAT histogram views the resulting large number of objects in package form

why

• A large number of proxy classes are generated during the run and cannot be unloaded
• The application runs for a long time without restart
• Meta space Settings are small

The solution

• Check the metacase size
• Check for a large number of launch operations in the code
• The dump file checks for the presence of a large number of proxy classes generated by reflection

GC overhead limit exceeded

• After JDK6, GC is too frequent, 98% of the time is GC, but less than 2% of the heap is reclaimed, which is poor
• Set the parameters-XX:-UseGCOverheadLimitDisable this check, reporting a heap overflow
• parameter

-XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=heap/heapdumpExceeded.hprof
-XX:SurvivorRatio=8
-Xms10M
-Xmx10M
-Xloggc:log/gc-comExceeded.log
Copy the code

The solution

• Whether there are lots of dead loops, or code with lots of memory
• Dump checks for memory leaks and enlarges the memory

Thread overflow

• unable to create new native Thread
• Creating a large number of threads
• Create a formula to calculate the number of threads

1. (MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
2. MaxProcessMemory The maximum space that a process can address for 64-bit operating systems 2^64
3. JVMMemory JVM memory
4. ReservedOsMemory specifies the ReservedOsMemory
5. ThreadStackSize Size of the thread stack

Performance tuning

Jmemter

• Download address
• Configure the environmentzprofile

Export JMETER_HOME = / Users/MZX/Desktop/Java/JVM/apache jmeter - 5.4.3 export PATH=$JAVA_HOME/bin:$PATH:.:$JMETER_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME/lib/j Orphan. Jar: $JMETER_HOME/lib/logkit - 2.0. The jarCopy the code

• Add thread groups to simulate access

• Set thread group parameters

• Add thread request

• Adding listeners

throughput

• Increase heap memory, decreasefullgcFrequency to improve throughput

JIT optimization

• For code that executes only once, it is more efficient to use an interpreter

1. Constructor of a class that is called only once
2. There is no loop code
3. Execute code only a few times

• Escape analysis was not performed-XX:-DoEscapeAnalysisGenerate a large number of objects

• Turn on escape analysis and there aren’t really that many objects

• Synchronously omitted, the bytecode is not directly omitted and is optimized at compile time

• Turn on scalar substitution-XX:+EliminateAllocationsEscape analysis makes sense for the JVMOn the stackIn fact, it isScalar replacement

Escape analysis is enabled, but scalar substitution is not

Turn on escape analysis, turn on scalar substitution

Escape analysis is not enabled

• summary

1. If after escape analysis, no object is not escape, then the process of escape analysis is wasted
2. There is no guarantee that performance will improve after escape analysis

Properly configure heap memory

• Xmx and Xms are set to old age objects3-4 times, i.e., 3-4 times the memory footprint of the older generation after FullGC
• The method area size is set to that of the old age living object1.2 to 1.5 times
• The young generation Xmn is set to the old generation survivable object1-1.5 times
• Force FullGC to fire

1. jmap -dump:live,forma=b,file=heap.bin <pid>Generates a dump file for the current living object
2. jmap -histo:live <pid>The number of instances of class, memory usage, and the full name of the class are printed. After adding live, only the number of live objects is counted
3. Testing tools

• Estimate the YGC frequency

• You are not advised to enable this function for systems with heavy traffic and low latencyUseAdaptiveSizePolicy

CPU

• Run on the server
• top -Hp 16195The percentage of threads running under a process

• jstack 16195 > jstack.logSaves thread information for the process
• You need to locate the process based on the PID hexadecimal

• jstack 16195 | grep -A20 3f44Go straight to the next 20 lines of the thread

• A deadlock to solve

1. Adjust the lock order to be consistent
2. A periodic lock is used. After a period of time, if the lock cannot be obtained, the lock itself is released

The impact of the number of G1 concurrent threads on performance

• ConcGCThreadsThe number of concurrent token threads is, at most, 1/4 of the user threads
• Can improve throughput

Adjust the garbage collector

• G1 Improves throughput

Daily million orders system

• throughput

• The response time is controlled at 100ms

1. G1 Sets the maximum STW time and the Java heap usage threshold

Other problems

• Reduce inventory and order, simultaneously asynchronously

Distributed local inventory + a separate server for inventory balancing

• 500, 000 PV data sites, servers and performance increases, lower efficiency

1. The original website has limited memory, frequent GC, long STW and slow response time
2. The reason is more sluggish, the larger the memory space, the longer the FGC time, the longer the delay time
3. Garbage collector, with priority given to G1, maximizes throughput with manageable latency; Adjust configuration parameters,MaxGCPauseMillis,ConcGCThreadsAnd heap space allocation; Dump file analysis to optimize memory space ratio

• CPU often 100%, tuning process

1. top -Hp 16195The percentage of threads running under a process
2. jstack 16195 > jstack.logSaves thread information for the process
3. jstack 16195 | grep -A20 3f44Go straight to the next 20 lines of the thread

• System memory is high

1. Specific tools, memory ratio, log situation
2. The dump file

• Monitoring the JVM

1. Command line tool
2. Graphical interface