This is the 13th day of my participation in the August More text Challenge. For details, see: August More Text Challenge

Needs three days to change, overtime for a month long,

Family members do not meet, anger brush progress wall.

Struggle to remember, the language of adjustment is not clear,

In this bitter tears, misidentification Tan Haoqiang.

This article Outlines some JVM startup parameters related to GC logging.

Basic parameters of GC logs

-xx :+PrintGCDetails Displays the GC log details. -xx :+PrintGCTimeStamps Displays the GC timestamp (in reference time). -xx :+PrintGCDateStamps Displays the GC timestamp (in date). As the 2013-05-04 T21:53:59. 234 + 0800) - XX: + PrintHeapAtGC print out before and after in the GC heap information - XX: + PrintGCApplicationStoppedTime output GC applications pause time -xx :+PrintReferenceGC reference information, the number of virtual, weak, and strong references and the time spent -xLoggc :.. /logs/gc.log Output path of the log fileCopy the code

Special note: production gc logs to follow the principle of enough is good, because the gc log time also will be in the STW time, if the gc log output is synchronized to brush plate model, likely because other IO system of gc pause time anomaly (caused by gc print anomaly and the next we described in detail below)

Special parameters related to GC logs

1. GC log scrolling

-XX:+UseGCLogFileRotation

Copy the code

The output of GC logs can cause file IO and sometimes unnecessary pauses. You can output GC logs to TMPFS (memory file system), but TMPFS consumes memory. To avoid wasting memory, use -xx :+UseGCLogFileRotation to scroll GC logs.

2. Forbid writing Statistics data

-XX:+PerfDisableSharedMem

Copy the code

GSTST will silently write statistics in the/TMP /hperf directory.

If you happen to see PageCache flush the disk, you will not be able to end the Stop the World safe point. Disable jstat with the above parameters and use JMX instead. See also: the JVM – mmap – pause

3. Related parameters of safety points

-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount = 1

Copy the code

Security point related logs are as follows:

Vmop [Threads: total initially_running wait_to_block][time: spin block sync cleanup vmop]page_trap_count 0.257: ParallelGCFailedAllocation [9 0 0] [0 0 0 0 2] 0 0.261: novmoperation [0, 1] 7 [0 0 0 0 0] 0Copy the code

  • vmop

  • Indicates the cause of raising STW

  • [thread]

  • Total: total number of threads in the safe point

  • Initially_running: The number of threads that were running at the start of the safe point

  • Wait_to_block: Number of threads that need to wait for a VM Operation to pause before it starts

  • [time]

  • Spin: The time it takes for a thread to respond to a SafePoint call

  • Block: The time it takes to suspend all threads

  • Sync :(spin + block), == time taken from the start to the safe point, which can be used to judge the time taken to enter the safe point

  • Cleanup: time required to cleanup

  • Vmop: time to actually execute VM Operation

No VM operation indicates that there is no VM operation taking place, so the representation is a safe point

_ Safety point _ Health monitoring of the system is very important. Safe points are used in scenarios such as GC, bias lock undo, etc., in short, to provide a state point where the object state is invariant to allow the system to perform a series of subsequent operations.

Another JVM parameter related to the safety point is mentioned here in passing: -xx: -usebiasedlocking

Disable biased locking set parameters, is more effective in some cases, if concurrent competition, leads to biased locking revocation is frequent, this time we may see security point time increased, leading to the gc and system response time increases, the safety points and biased locking abnormal case, we are also listed in the next article

Add: special parameters related to performance and tuning

1. Dump parameters

This should not be a gc log related parameter, but it is all in the JVM startup parameters, just in case

  • 1.heap dump
-XX:+HeapDumpOnOutOfMemoryError

Copy the code

This parameter, main effect is that the system oom exception occurs, automated heap dump operation, some bosses said in container environment situation, in the ordinary hard disk can cause more than 20 seconds of hard disk IO run full, for other host program is very unfriendly, but according to the actual situation of the production operations, this parameter is very useful, When oom exceptions occur and the system needs to be restarted and restored as soon as possible, the dump field files are very helpful for troubleshooting.

  • 2.core dump
ulimit -c unlimited

Copy the code

From CoreDump, we can transfer Heap Dump and Thread Dump and crash, which is very useful

2. Integer Cache

-XX:AutoBoxCacheMax=20000

Copy the code

For integers and longs, the JDK only caches -128 to +127 by default, and new Integer objects are built in real time for numbers out of the range. This parameter can be set for a system with high performance requirements. According to relevant calculations, the impact of QPS is about 4%.

3. Pre-access during startup

-XX:+AlwaysPreTouch

Copy the code

This parameter is set for Both ElasticSearch and Cassandra. It is used for pre-access to memory pages, which may be slower to start but faster to access. For example, when a new generation is promoted to an old generation, it does not temporarily visit pages, resulting in longer GC pauses.

4. Just-in-time compilation

-XX:-UseCounterDecay
-XX:-TieredCompilation

Copy the code

By default, GC performs technical decaying, and methods that may result in some critical pageviews remain unconverted to hot code, so you can use the UseCounterDecay parameter to disable counter decay. TieredCompilation is a multitier compilation that is enabled by default in 1.8. But industry leaders in the field test found that the initial performance may be weakened, there is a need to disable it.

conclusion

This article provides an overview of some of the parameters involved in GC logging that you may need to pay attention to. It also lists some JVM startup parameters related to performance, which can be used as a reference when you encounter similar problems.

Of course, there are many JVM startup parameters related to GC, such as GC policy, number of concurrent collection threads, ratio of Eden to s block, age of objects, fragmentation of CMS, pause time of G1, etc., each of which can be explained in a separate article based on actual requirements. You can add more later when you have a chance