This translation from: www.redhat.com/en/blog/col...
This article will delve into the log and tuning parameters G1. In order to G1 tune in practical work, as a developer you need to understand each step G1 garbage collector, and the role of each step in the overall garbage collection cycle. In order to facilitate the reader to learn, this article will log parameter G1 is divided into three levels increasing, this article will introduce each scene and the role of each part of the tuning parameters when used.
- Basic parameters - using the G1 collector in production, these parameters must be used
- Advanced parameters - with the maturity increased traffic load or application, you need to use these parameters tuned for certain issues.
- Debug parameters - These parameters are used to address specific performance issues if a problem can not be reproduced in a non-production environment, these parameters will be used to troubleshoot problems in a production environment.
Basic parameters
If you want to use the G1 GC in a production environment, the following parameters related with logs is a must, with these parameters, you can troubleshoot basic garbage collection problems.
Use -XX:GCLogFileSize
to set the appropriate GC log file size, use -XX:NumberOfGCLogFiles
the number of GC log file settings to be retained, the use -Xloggc:/path/to/gc.log
to set the location of the log file GC, GC to retain log information used in the process of running through the three parameters above, I recommend reservations at least one week the GC logs runtime information sufficient number of such applications, easy to troubleshoot.
New Generation collection
And, like other garbage collector, G1 also be used -XX:PrintGCDetails
to print a detailed log garbage collection, the picture below is the new generation of standard processes to collect, here I will divide it into six steps:
- Four key information
- The new generation garbage collection time of occurrence - 2016-12-12T10: 40: 18.811-0500 , by setting
-XX:+PrintGCDateStamps
the parameter can print out this time; - Relative time after JVM startup - 25.959
- This type of collection - the new generation of the collection, only the recovery partition Eden
- The time it takes to collect - 0.0305171s, namely 30ms
- The new generation garbage collection time of occurrence - 2016-12-12T10: 40: 18.811-0500 , by setting
- It shows the detailed procedure of the new generation of parallel collector collection
- Time Parallel : Parallel collection tasks initiated during operation STW (Stop The World) time, the new generation garbage collection from the beginning to the end of the last task, a total cost of 26.6ms
- Workers GC : There are four threads responsible for garbage collection, parameter
-XX:ParallelGCThreads
settings, set the value of this parameter, related with the CPU, if the number of threads supported by less than 8 physical CPU is set to a maximum of 8; if the physical CPU supports two threads number is larger than 8, the default number * 5/8 - Worker Start GC : The first garbage after time (min) JVM startup time of collection thread begins work; JVM started when the last garbage collection thread started working elapsed time (max); diff represents the difference between min and max value. Ideally, you want them to start almost simultaneously, that is, diff close to zero.
- Root Scanning EXT : scanning root collection time (thread stack, JNI, global variables, system tables, etc.) spent scanning root is the starting point of the collection of garbage collection, try to find whether there is a set of root node points to the current collection set (CSet )
- RS Update (Remembered the Set or RSet) : Each partition has its own RSet, used to record other partition points to the current partition pointer, if RSet updates, there will be cross-referenced partition of a post-write barrier management in G1 - new referenced card will be marked as dirty, and placed in a log buffer, if the buffer is full the log will be added to a global buffer, as well as concurrent processing threads in this process JVM running dirty global log buffer card. Update RS Permits garbage collection thread processing is not handled well log buffer Before the start of garbage collection, which ensures RSet current partition is up to date.
- Buffers Processed , which indicates how many log buffer processing Update RS this process.
- RS Scan : Scan RSet each new generation of partition, find out how many points of reference to the current partition from CSet.
- Code Root Scanning time root node (local variables) spent in the scan code:
- Copy Object : During the evacuation pause, all partitions in CSet must be transferred to evacuate, Object Copy to copy the current partition will be responsible for the survival of the object to the new partition.
- Termination : When a garbage collection thread to complete the task, it will enter a critical region, and try to help other junk thread to complete the task (steal outstanding tasks), min indicate when the garbage collector thread attempts to terminatie, max indicates that the garbage collection recovery when the real thread terminated.
- Attempts Designates, in Termination : If a garbage collection thread other threads mission successfully steal, then steal it again or try to terminate more tasks again, each time re-terminate when this value will increase.
- Worker Other GC : Garbage collection thread at a time to complete other tasks
- Total Worker GC : show the minimum each garbage collection thread, maximum, average, and the difference in total time.
- Worker End GC : min represents the time after the JVM starts at the end of the first end of the garbage collection thread; max indicates the time after the end of the JVM to start garbage collection no later than the end of the thread. Ideally, you want them to end quickly, and preferably end at the same time.
- It lists some of the tasks of the new generation GC:
- Root the Fixup Code : releasing a data structure for managing concurrent garbage collection events, should be close to 0, this step is performed linear;
- Root the Purge Code : cleaning more data structures, should soon, consuming close to 0, is a linear actuator.
- Clear CT:清理card table
- It contains extended features
- CSet the Choose : Select the partition to be recycled into CSet (G1 selection criteria are the most littered partition priority, which is the lowest survival rate of partition object priority)
- Proc ref : processing a variety of Java references --soft, weak, final, phantom, JNI , and so on.
- Enq ref : traversing all references will not be recycled into the pending list
- Card Redirty : modified during recovery card will be reset as dirty
- The Register the Humongous : JDK8u60 provides a feature, huge objects can be recovered at the time of collection of the new generation - by
G1ReclaimDeadHumongousObjectsAtYoungGC
setting default is true. - Reclaim Humongous : Time to do the following tasks: to ensure the massive object can be recovered, the release of the giant target share partition, reset the partition type, and also to free the partition list and updates the free space.
- CSet as Free : Zoning also to be released back to the free list.
- It shows the variation in the size of different generations, and adaptively adjust the size of the heap.
- Eden: 1097.0M (1097.0M) -> 0.0B (967.0M) : The reason (1) of the current young generation collections triggered Eden space is full, assigned 1097M, using the 1097M; (2) all partitions are Eden the evacuation process, the use of the new generation after Eden partition size becomes 0.0B; size (. 3) is reduced to Eden partition 967.0M
- Survivors: 13.0M-> 139.0M : Due to the young generation recycling partitions, survivor space rose from 13.0M 139.0M;
- Heap: 1694.4M (2048.0M) -> 736.3M (2048.0M) : (1) at the time of this garbage collection activities began, the overall amount of heap space is 1694.4M, maximum heap space is 2048M; (2) at the end of this garbage collection, the amount of heap space is 763.4M, the maximum value remains unchanged.
- Point 6 shows the time this new generation garbage collection
- = 0.8 the User : garbage collection thread consumption in the new generation garbage collection process CPU time, this time to talk about the number of garbage collection threads, may be much larger than real time;
- 0.0 = SYS : kernel mode thread CPU time consumed - Real = 0.03 : The garbage collection time real consumption;
Concurrent garbage collection
The second collection activities G1 is concurrent garbage collection, triggers concurrent garbage collection are many, but doing the same work, its log as shown below:
-
Concurrent garbage collection phase marks the beginning:
- PAUSE GC (G1 Evacuation Pause) (Young) (Initial-Mark) : In order to take full advantage of the opportunity to trace all STW up (survival) of an object, initial-mark stage as part of a new generation of garbage collection in the presence of (take it car). initial-mark are provided two TAMS (top-at-mark- start) variables used to distinguish live objects and newly allocated objects concurrent marking phase. All objects before the TAMS, in the current period will be considered viable.
-
Concurrent mark represents the first stage of doing things: the root partition scan
- Concurrent-root-Region GC-Scan-Start : scan start root partition, root partition scan the main scanning is the new survivor district, find the object of these sub-region point to refer to the current partition, if found to have reference, to be recorded;
- Concurrent-root-Region GC-Scan-End : root partition scan is finished, time-consuming 0.0030613s
-
It represents the concurrent mark phase
- Concurrent Mark-Start-GC : concurrent mark phase begins. (1) concurrent mark phase of the thread is the thread running together with the application, will not be STW, so called concurrent; garbage collection thread concurrent mark phase, the default value is 25% of the number of Parallel Thread, this value can also use the parameter
-XX:ConcGCThreads
set; (2) trace the entire heap, and using bitmap mark all surviving objects, because the object before top TAMS is implicit viable, so here only need to mark those before after top TAMS, the threshold value; (3 ) record changes in concurrent mark phase, G1 used here SATB algorithm requires when garbage collection begins to take a snapshot of the heap, the garbage collection process this snapshot is unchanged, but in fact certainly some objects reference will change, this time using the G1 pre-write barrier recording this change, and store this record in a SATB buffer, if the buffer is full it will be added to a global buffer, while G1 has a thread processing in parallel to obtain the global buffer; (4) during the concurrent mark will be recorded live objects for each partition of the total The size of the area ratio; - Concurrent Mark-End-GC : concurrent mark phase ends, time-consuming 0.3055438s
- Concurrent Mark-Start-GC : concurrent mark phase begins. (1) concurrent mark phase of the thread is the thread running together with the application, will not be STW, so called concurrent; garbage collection thread concurrent mark phase, the default value is 25% of the number of Parallel Thread, this value can also use the parameter
-
Re-mark phase, will Stop the World
- Marking the Finalize : Finalizer Finalizer list of object processing, time-consuming 0.0014099s;
- REF-proc the GC : reference (soft, weak, final, phantom , JNI etc.) process, takes 0.0000480s;
- Unloading : Uninstall class, time-consuming 0.0025840s;
- In addition to in front of these things, the most important result of this stage are: to map out the final appearance of the current cycle of concurrent entire heap, SATB remaining buffer will be processed here, all live objects will be marked;
-
Clean-up phase, will Stop the World
- Finally, live objects calculated: marked object is assigned a stage after the initial-mark; mark live objects have at least one partition;
- To prepare for the next stage concurrent mark, previous and next bitmap will be cleaned up;
- No live objects old giant's partition and target partition will be released and cleanup;
- Treatment did not RSet any partition of live objects;
- All years old partition will be sorted according to their own survival (survival target ratio of the total size of the district), in preparation for the selection process CSet back;
-
Concurrent clean-up stage
- Cleanup Start-Concurrent-GC : Concurrent cleaning phase starts. Complete step 5 the rest of the clean-up work; completely clean up good two free partitions added to the list, waiting list will eventually free to overall;
- Concurrent-Cleanup-End GC : concurrent cleanup phase is completed, time-consuming 0.0012954s
Mixed collection
At the end of the concurrent collection phase, you will see a mix of log collection phase, as shown below, the same as most of the discussion with the new generation of the log before the collection, only the first part is not the same: GC PAUSE (G1 Evacuation Pause) (mixed), 0.0129474s , this line indicates that this is a mixed garbage collection cycle; CSet mixed garbage collection process includes not only the new generation of partition, also include old's partition - that is, the concurrent marking phase mark out those old years partition.
Full GC
If space is insufficient heap memory to allocate a new object, or Metasapce space usage reaches the set threshold, it will trigger Full GC-- you should when using the G1 as much as possible to avoid this from happening, because the G1 Full Gc is single-threaded, will Stop The World, the cost is very high. Full GC log shown below, three types of information from which you can see
- Full GC of reasons, this figure is Allocation Failure, there is a common cause of Metadata GC Threshold;
- Full GC occurrence frequency, occurs once every few days Full GC also acceptable, but 1 hour occur once every Full GC is unacceptable;
- Full GC time-consuming, this picture of Full GC takes 150ms (PS: In my experience, if the actual operation of Full GC occurs, will be a lot more time-consuming than this)
Basic configuration parameters, I would like to introduce here two: -XX:+PrintGCApplicationStoppedTime
and -XX:+PrintGCApplicationConcurrentTime
, these two parameters can also provide useful information for you, as shown below:
- Records the total time (that is, the total time STW) application thread is suspended at the point of security
- Records for all application threads into a safe point total time spent
- It records the time of application threads running between two security points
to sum up
This article is to translate the text of the first part, the basic parameters chapter, I am going to have one or two articles to complete the advanced parameters and parameter Debug two parts of the original text. ------
This focus on the number of back-end technology, JVM troubleshooting and optimization, Java interview questions, personal growth and self-management, and other topics, providing front-line developers work and growth experience for the reader, you can expect to gain something here.