Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to understand JVM tuning parameters, methods, tools". In daily operation, I believe many people have doubts about how to understand JVM tuning parameters, methods and tools. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to understand JVM tuning parameters, methods and tools"! Next, please follow the editor to study!

Parameters related to garbage collection

In the parameters section, this is just a summary. For more detailed updates, please refer to the command line parameters of Oracle website: JVM.

Processor combination parameters

About the difference of JVM garbage processor, refer to: JVM optimized garbage location, garbage collection algorithm, garbage processor comparison

-XX:+UseSerialGC = Serial New (DefNew) + Serial Old

Suitable for small programs. This option is not available by default, and HotSpot automatically selects the collector based on the calculation and configuration and the JDK version

-XX:+UseParNewGC = ParNew + SerialOld

This combination is rarely used (obsolete in some versions). For more information, please see Why Remove support for ParNew+SerialOld and DefNew+CMS in the future?

-XX:+UseConc (urrent) MarkSweepGC = ParNew + CMS + Serial Old

-XX:+UseParallelGC = Parallel Scavenge + Parallel Old (1.8 default) [PS + SerialOld]

-XX:+UseParallelOldGC = Parallel Scavenge + ParallelOld

-XX:+UseG1GC = G1

No way to view the default GC is found in Linux, but UseParallelGC is printed in windows

Java + XX:+PrintCommandLineFlags-version

Tell the difference by GC's log

What exactly is the default garbage collector for version 1.8 of Linux?

1.8.0x181 default (invisible) Copy MarkCompact

1.8.00222default PS + PO

Virtual machine parameters

Parameters related to parallel collector

CMS processor parameter settings

JVM Auxiliary Information Parameter Settings

JVM GC garbage Collector Parameter Settings

JVM gives three options: serial collector, parallel collector, and concurrent collector. Serial collector is only suitable for small amount of data, so the choice of production environment is mainly parallel collector and concurrent collector. By default, JDK5.0 used to use serial collectors, and if you want to use other collectors, you need to add the appropriate parameters at startup. After JDK5.0, JVM will make intelligent judgments based on the current system configuration.

Serial Collector-XX:+UseSerialGC: sets the serial collector.

Parallel collector (throughput first)-XX:+UseParallelGC: set to parallel collector. This configuration is valid only for the younger generation. That is, the younger generation uses parallel collection, while the older generation still uses serial collection.

-XX:ParallelGCThreads=20: configure the number of threads in the parallel collector, that is, how many threads are garbage collected at the same time. This value recommends that the configuration be equal to the number of CPU.

-XX:+UseParallelOldGC: configure the old generation garbage collection method to collect in parallel. JDK6.0 began to support parallel collection of older generations.

-XX:MaxGCPauseMillis=100: sets the maximum time (in milliseconds) for each young generation garbage collection. If this time cannot be met, JVM automatically resizes the younger generation to meet this time.

-XX:+UseAdaptiveSizePolicy: when this option is set, the parallel collector will automatically adjust the ratio of Eden area size to Survivor area size of the younger generation to achieve the minimum response time or collection frequency specified by the target system. This parameter recommends that you keep it on when using a parallel collector. Concurrent collector (response time first)

Parallel collector

-XX:+UseConcMarkSweepGC: that is, CMS collection. Set the older generation to collect concurrently. CMS collection is a new GC algorithm introduced in later versions of JDK1.4. It is mainly suitable for scenarios where the importance of response time is greater than that of throughput, it can withstand garbage collection threads and application threads to share CPU resources, and there are many long life cycle objects in the application. The goal of CMS collection is to minimize the pause time of the application, reduce the probability of Full GC occurrence, and use garbage collection threads concurrent with application threads to mark and clear the older generation of memory.

-XX:+UseParNewGC: set the younger generation to collect concurrently. Can be used in conjunction with CMS collection. Above JDK5.0, JVM will be set according to the system configuration, so it is no longer necessary to set this parameter.

-XX:CMSFullGCsBeforeCompaction=0: since the concurrent collector does not compress and organize the memory space, running parallel collection for a period of time will result in memory fragmentation and reduce memory usage efficiency. This parameter sets the memory space to be compressed and sorted out after running Full GC for 0 times, that is, the memory will be compressed and sorted immediately after each Full GC.

-XX:+UseCMSCompactAtFullCollection: turn on the compression and consolidation of memory space, which is executed after Full GC. It may affect performance, but memory fragmentation can be eliminated.

-XX:+CMSIncrementalMode: set to incremental collection mode. It is generally applicable to the case of single CPU.

-XX:CMSInitiatingOccupancyFraction=70: indicates that CMS collection starts when the older generation uses 70% of the memory space to ensure that the older generation has enough space to accept objects from the younger generation to avoid the occurrence of Full GC.

Other garbage collection parameters

-XX:+ScavengeBeforeFullGC: the younger generation of GC is better than FullGC.

-XX:-DisableExplicitGC: does not respond to the System.gc () code.

-XX:+UseThreadPriorities: enables the local thread priority API. Even if java.lang.Thread.setPriority () takes effect, it has no effect if it is not enabled.

-XX:SoftRefLRUPolicyMSPerMB=0: the soft reference object survives 0 milliseconds after it is last accessed (JVM defaults to 1000 milliseconds).

-XX:TargetSurvivorRatio=90: allows 90% of the Survivor area to be occupied (JVM defaults to 50%). Increase the utilization of the Survivor area.

JVM parameter priority

-Xmn,-XX:NewSize/-XX:MaxNewSize,-XX:NewRatio 3 sets of parameters can affect the size of the younger generation. In the case of mixed use, what is the priority?

The answers are as follows:

High priority:-XX:NewSize/-XX:MaxNewSize priority:-Xmn (default equivalent-Xmn=-XX:NewSize=-XX:MaxNewSize=?) low priority:-XX:NewRatio

The-Xmn parameter is recommended because it is concise, equivalent to setting NewSize/MaxNewSIze at one time, and the two are equal, suitable for production environments. -Xmn with-Xms/-Xmx to complete the heap memory layout.

The-Xmn parameter is supported since JDK 1.4.

Here are some small examples to deepen our understanding:

HelloGC is a class file compiled with java code, code:

Public class T01_HelloGC {public static void main (String [] args) {for (int iTun0) I392K (39936K), 0.0015452 secs] [GC (Allocation Failure) 7720K-> 336K (39936K), 0.0005439 secs] [GC (Allocation Failure) 7656K-> 336K (39936K), 0.0005749 secs] [GC (Allocation Failure) 7659K-> 368K (39936K), 0.0005095 secs] [GC (Allocation Failure) 7693K-> 336K (39936K), 0.0004385 secs] [GC (Allocation Failure) 7662K-> 304K (40448K), 0.0028468 secs].

The command explains:

Java: use java executor to execute-Xmn10M: set the younger generation to 10m-Xms40M: set the minimum heap value to 40m-Xmx60M: set the maximum heap value to 60m-XX:+PrintCommandLineFlags: print implicit parameters The first three lines of the result-XX:+PrintGC: print garbage collection related information HelloGC: this is the startup class that needs to be executed PrintGCDetails: print GC details PrintGCTimeStamps: print GC timestamp PrintGCCauses: print GC

The result explains:

3. Java-XX:+UseConcMarkSweepGC-XX:+PrintCommandLineFlags HelloGC

Means to use the CMS garbage collector while printing the parameters to print the result:

-XX:InitialHeapSize=61780800-XX:MaxHeapSize=988492800-XX:MaxNewSize=329252864-XX:MaxTenuringThreshold=6-XX:OldPLABSize=16-XX:+PrintCommandLineFlags-XX:+UseCompressedClassPointers-XX:+UseCompressedOops-XX:+UseConcMarkSweepGC-XX:+UseParNewGC

4. Default parameter values of java-XX:+PrintFlagsInitial

5. Java-XX:+PrintFlagsFinal final parameter value

6. Java-XX:+PrintFlagsFinal | grep xxx finds the corresponding parameter

7. Java-XX:+PrintFlagsFinal-version | grep GC

JVM tuning proc

JVM tuning is designed to three major aspects. Before there is a problem with the server, it is necessary to select the appropriate garbage processor according to the business scenario, set different virtual machine parameters, observe GC logs, analyze performance, analyze problem location, virtual machine troubleshooting and other contents. If the server crashes, log files should be generated in time to find the problem.

Basic concepts before tuning

Among the current garbage handlers, one type gives priority to throughput and the other gives priority to response time:

Throughput = user code execution time user code execution time + garbage collection execution time throughput = user code execution time user code execution time + garbage collection execution time

Response time: the shorter the STW, the better the response time

For concepts related to throughput, response time, QPS and concurrency, please refer to the concepts of throughput (TPS), QPS, concurrency and response time (RT).

The so-called tuning, first of all to determine what to pursue, is throughput? Or the pursuit of response time? Or in the case of meeting a certain response time, how much throughput is required, and so on. In general, the pursuit of throughput has the following areas: scientific computing, data mining and so on. The garbage processor combination that gives priority to throughput is generally Parallel Scavenge + Parallel Old (PS + PO).

The businesses that pursue response time are: website-related (G1 after JDK 1.8and ParNew + CMS + Serial Old before)

What is tuning?

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

JVM planning and pre-tuning according to demand

Optimize the running environment of JVM (slow, stutter)

Solve all kinds of problems during the operation of JVM (OOM)

Planning before tuning

Tuning, starting with business scenarios, tuning without business scenarios is hooliganism.

No monitoring (stress test, you can see the results), no tuning

Steps:

1.

two。 Or generate a log file every day

1. Response time, pause time [CMS G1 ZGC] (need to respond to the user)

two。 Throughput = user time / (user time + GC time) [PS+PO]

1. Familiar with business scenarios (there is no best garbage collector, only the most suitable garbage collector)

two。 Select recycler combination

3. Calculate memory requirements (experience 1.5G 16G)

4. Select CPU (as high as possible)

5. Set the age and upgrade age

6. Set log parameters

-Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log-XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=5-XX:GCLogFileSize=20M-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCCause

Explanation of log parameters:

In / opt/xxx/logs/xxx-xxx-gc-%t.log, XXX indicates the path, and% t indicates a timestamp, which means to add a time stamp to the log file. If it is not added, it means that the original log name will be used every time the virtual machine is started, so it will be rewritten.

Rotation in Chinese means cycle or rotation, which means that the GC log will be written in a cycle.

GCLogFileSize=20M specifies a log size of 20m, which is too large for analysis. Too small will result in too many log files.

NumberOfGCLogFiles=5: specifies the number of logs generated

PrintGCDateStamps: PrintGCDateStamps prints the exact time, while PrintGCTimeStamps

Printing is mainly aimed at the relative time when JVM starts, and the former consumes more memory.

7. Observe the log log there are analysis tools, visual analysis tools are GCeasy and GCViewer.

CPU heavy load troubleshooting process

1. The system CPU is often 100%. How to tune it? (high frequency of interview) CPU100%, then there must be threads taking up system resources.

a. Find out which process has the highest cpu (top)

b. Which thread in this process has a high cpu (top-Hp)

c. Export the thread's stack (jstack)

d. Find out which method (stack frame) consumes time (jstack)

e. High proportion of worker threads | High proportion of garbage collection threads

two。 The memory of the system is high, how to find the problem? (high frequency of interview)

a. Export heap memory (jmap)

b. Analysis (jhat jvisualvm mat jprofiler...)

3. How to monitor JVM

A. Jstat jvisualvm jprofiler arthas top...

Cases of CPU heavy load troubleshooting

1. Test the code:

Import java.math.BigDecimal; import java.util.ArrayList; import java.util.Date; import java.util.List; import java.util.concurrent.ScheduledThreadPoolExecutor; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit / * read credit data from the database, apply the model, and record and transmit the results * / public class T15_FullGC_Problem01 {private static class CardInfo {BigDecimal price = new BigDecimal (0.0); String name = "Zhang San"; int age = 5; Date birthdate = new Date () Public void m () {}} private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor (50, new ThreadPoolExecutor.DiscardOldestPolicy ()); public static void main (String [] args) throws Exception {executor.setMaximumPoolSize (50); for (;) {modelFit (); Thread.sleep }} private static void modelFit () {List taskList = getAllCardInfo (); taskList.forEach (info-> {/ / do something executor.scheduleWithFixedDelay (()-> {/ / do sth with info info.m ()) }, 2,3, TimeUnit.SECONDS);} private static List getAllCardInfo () {List taskList = new ArrayList (); for (int I = 0; I < 100; iTunes +) {CardInfo ci = new CardInfo (); taskList.add (ci);} return taskList }}

2. Java-Xms200M-Xmx200M-XX:+PrintGC com.courage.jvm.gc.T15_FullGC_Problem01

3. Received CPU alarm message (CPU Memory)

4. The top command observed a problem: memory is growing and CPU occupancy remains high.

[root@localhost] # top top-22:03:18 up 40 min, 5 users, load average: 0.09,0.16,0.34 Tasks: 210 total, 1 running, 209 sleeping, 0 stopped, 0 zombie% Cpu (s): 0.2 us, 3.0 sy, 0.0 ni, 96.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 3861300 total, 2355260 free, 904588 used 601452 buff/cache KiB Swap: 4063228 total, 4063228 free, 0 used. 2716336 avail Mem PID USER PR NI VIRT RES SHR S% CPU% MEM TIME+ COMMAND 3751 root 20 0 3780976 93864 11816 S 42.2 2.4 0 root 21.00 java 1868 mysql 20 1907600 357452 14744 S 0.7 9.30 avail Mem PID USER PR NI VIRT RES SHR S 17.40 mysqld 3816 root 20 0 162124 2352 1580 R 0.3 0.01 MEM TIME+ COMMAND 00.12 top

5. Top-Hp observes the threads in the process, which thread accounts for a high proportion of CPU and memory

[root@localhost] # top-Hp 3751 top-22:03:15 up 40 min, 5 users, load average: 0.09,0.16,0.34 Threads: 66 total, 0 running, 66 sleeping, 0 stopped, 0 zombie% Cpu (s): 0 us, 2 5 sy, 0 ni, 97 5 id, 0 wa, 0 hi, 0 si, 0 st KiB Mem: 3861300 total 2354800 free, 905048 used, 601452 buff/cache KiB Swap: 4063228 total, 4063228 free, 0 used. 2715876 avail Mem PID USER PR NI VIRT RES SHR S% CPU% MEM TIME+ COMMAND 3801 root 20 0 3780976 93864 11816 S 1.3 2.4 0 java 3766 root 20 0 3780976 93864 11816 S 1.0 2.40 java 3768 root 20 0 3780976 93864 11816 S 1.0 0.36 java 3770 root 20 0 3780976 93864 11816 S 1.0 2.4 0:00.39 java

6. Jps locates specific java processes, and jstack locates thread status

[root@localhost ~] # jstack 3751 2021-02-07 22:03:03 Full thread dump Java HotSpot (TM) 64-Bit Server VM (25.271-b09 mixed mode): "Attach Listener" # 59 daemon prio=9 os_prio=0 tid=0x00007f66bc002800 nid=0xf10 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "pool-1-thread-50" # 58 prio=5 os_prio=0 tid=0x00007f66fc1de800 nid=0xee7 waiting on condition [0x00007f66e4ecd000] java.lang.Thread.State: WAITING (parking) At sun.misc.Unsafe.park (Native Method)-parking to wait for (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject).

It should be noted that there is a hexadecimal conversion relationship between the stack port numbers of jstack and top-Hp Port exports, for example, "nid=0xf10" of jstack exports corresponds to "3801". For the information printed above, focus on what is related to Waiting and see what you are waiting for, for example:

WAITING BLOCKED eg. Waiting on (a java.lang.Object)

If there are 100 threads in a process, many threads are in waiting on, be sure to find out which thread holds the lock, how to find it? Search for jstack dump information to see which thread holds the lock RUNNABLE.

If you are just looking at JAVA threads, you can use the jps command to focus on:

[root@localhost ~] # jps 4818 Jps 4746 T15_FullGC_Problem01

7. Why does the Ali specification stipulate that the name of a thread (especially the thread pool) should be meaningful? how to customize the name of the thread in the thread pool? (custom ThreadFactory)

8. Jinfo pid process details

[root@localhost ~] # jinfo 6741 Attaching to process ID 6741, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.271-b09 Java System Properties: java.runtime.name = Java (TM) SE Runtime Environment java.vm.version = 25.271-b09 sun.boot.library.path = / usr/local/java/jdk1.8.0_271/jre/lib/amd64 java.vendor.url = http://java.oracle.com/ java.vm.vendor = Oracle Corporation path.separator =: file.encoding.pkg = sun.io java.vm.name = Java HotSpot (TM) 64-Bit Server VM sun.os.patch.level = unknown sun.java.launcher = SUN_STANDARD user.country = CN user.dir = / usr/courage/gc/com/courage java.vm.specification.name = Java Virtual Machine Specification java.runtime.version = 1.8.0_271-b09 java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment os.arch = amd64 java.endorsed.dirs = / usr/local/java/jdk1.8.0_271/jre/lib/endorsed java.io.tmpdir = / tmp line.separator = java .vm.specification.specificity = Oracle Corporation os.name = Linux sun.jnu.encoding = UTF-8 java.library.path = / usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/ libjava.specification.name = Java Platform API Specification java.class.version = 52.0 sun.management.compiler = HotSpot 64-Bit Tiered Compilers os.version = 3.10.0-1127.el7.x86_64 user.home = / root user.timezone = java.awt.printerjob = Sun.print.PSPrinterJob file.encoding = UTF-8 java.specification.version = 1.8 user.name = root java.class.path =. Java.vm.specification.version = 1.8 sun.arch.data.model = 64 sun.java.command = T15_FullGC_Problem01 java.home = / usr/local/java/jdk1.8.0_271/jre user.language = zh java.specification.vendor = Oracle Corporation awt.toolkit = sun.awt.X11.XToolkit java.vm.info = mixed mode java.version = 1.8.0271 java.ext.dirs = / usr/local/java/jdk1.8.0_271/jre/lib/ext : / usr/java/packages/l ib/extsun.boot.class.path = / usr/local/java/jdk1.8.0_271/jre/lib/resources.jar:/usr / local/java/jdk1.8.0_271/jre/lib/rt.jar:/usr/local/java/jdk1.8.0_271/jre/lib/sunrsasign.jar:/usr/local/java/jdk1.8.0_271/jre/lib/jsse.jar:/usr/local/java/jdk1 .8.0_271/jre/lib/jce.jar:/usr/local/java/jdk1.8.0_271/jre/lib/charsets.jar:/usr/local/java/jdk1.8.0_271/jre/lib/jfr.jar:/usr/local/java/jdk1.8.0_271/jre/classesjava.vendor = Oracle Corporation file.separator = / java.vendor.url.bug = http://bugreport.sun.com/bugreport/ sun.io.unicode.encoding = UnicodeLittle Sun.cpu.endian = little sun.cpu.isalist = VM Flags: Non-default VM flags:-XX:CICompilerCount=3-XX:InitialHeapSize=209715200-XX: MaxHeapSize=209715200-XX:MaxNewSize=69730304-XX:MinHeapDeltaBytes=524288-XX:NewSize=69730304-XX:OldSize=139984896-XX:+PrintGC-XX:+UseCompressedClassPointers-XX:+UseCompressedOops-XX:+UseFastUnorderedTimeStamps-XX:+UseParallelGC Command line:-Xms200M-Xmx200M-XX:+PrintGC

9. Jstat-gc orbit gc / read GC log to find frequent GC / arthas observation / jconsole/jvisualVM/ Jprofiler (preferably)

Jstat gc 4655 500: printing the GC of port 4655 every 500ms

* * the size of the first survival area of S0Corel

* * the size of the second survival area of S1Cvirtual

* * the size of the first survival area used by S0UVR regions *

* * the size of the second survival area used by S1UDrex

* * the size of EC:** Eden Park

* * usage size of EU:** Eden Park

* * the old age of OC:**

* * OU:** used size in the old days

* * MC:** method area size

* * MU:** method area uses size

* * CCSC:** compressed class space size

* * CCSU:** compressed class space usage size

* * the number of garbage collection of YGC:** 's younger generation

* * time spent on garbage collection of the younger generation of YGCT:**

* * the number of garbage collection in the old years of FGC:**

* * garbage collection time spent in the old years of FGCT:**

* * Total time spent on GCT:** garbage collection

If the interviewer asks you how to position the OOM question? Can you use a graphical interface (no! Because the graphical interface will affect the performance of the server) 1: what does the system that is already online use without a graphical interface? (cmdline arthas) 2: what exactly is the graphical interface used for? test! Monitor during the test! (pressure test observation)

10. Jmap-histo 6892 | head-10 to find out how many objects are generated

This obviously shows that the class corresponding to 1 creates too many instances of instances, which in turn traces the code.

11. Jmap-dump:format=b,file=xxx pid:

Online systems with large memory will have a great impact on the process during jmap execution, even stutter (not suitable for e-commerce) 1: heap dump files will be generated automatically when the parameter HeapDump,OOM is set. 2: many servers are backed up (highly available). Stopping this server will not affect other servers 3: online positioning (generally not used by smaller companies)

[root@localhost ~] # jmap-dump:format=b,file=2021_2_8.dump 6892 Dumping heap to / root/2021_2_8.dump... Heap dump file created

Location of dump files:

12. Java-Xms20M-Xmx20M-XX:+UseParallelGC-XX:+HeapDumpOnOutOfMemoryError com.courage.jvm.gc.T15_FullGC_Problem01 means that a heap dump file is automatically generated when a memory overflow occurs. It is important to note that if this file is generated, do not restart the server, save the file and then restart it.

13. Use MAT / jhat / jvisualvm to analyze dump files

[root@localhost ~] # jhat-J-Xmx512M 2021_2_8.dump

Error report:

The reason is that the heap maximum set is too small. Set 512m to 1024m to restart:

````shell [root@localhost ~] # jhat-J-Xmx1024M 2021_2_8.dump Reading from 2021 February 2. Dump. Dump file created Mon Feb 08 09:00:56 CST 2021 Snapshot read, resolving... Resolving 4609885 objects... Chasing references, expect 921 dots... .Eliminating duplicate references.. .. .Snapshot resolved. Started HTTP server on port 7000 Server is ready. ```The browser can view it by entering the request http://192.168.182.130:7000, and pull it to the end: find the corresponding link and use OQL to find specific problem objects.

Others can be referred to: White Ash-Software testing

14. Finally, the problem of finding the code

JVM tuning tool jconsole remote connection

1. Program startup add parameters:

Java-Djava.rmi.server.hostname=192.168.182.130-Dcom.sun.management.jmxremote-Dcom.sun.management.jmxremote.port=11111-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.jmxremote.ssl=false XXX

two。 If you encounter a Local host name unknown:XXX error, modify the / etc/hosts file to add XXX

192.168.182.130 basic localhost localhost.localdomain localhost4 localhost4.localdomain4:: 1 localhost localhost.localdomain localhost6 localhost6.localdomain6

3. Turn off the linux firewall (the corresponding port should be opened in practice)

Service iptables stop chkconfig iptables off # permanently shut down

4. Open the jconsole remote connection 192.168.182.130Ru 11111 on windows

Jvisualvm remote connection

This software has been removed in later versions of JDK8 and requires additional download if used, and the default JDK_Home address needs to be changed in etc/visualvm.conf. Reference: remote monitoring of Java programs using jvisualvm's jstatd method

Alibaba Arthas

This goes directly to the official website, pure Chinese: Arthas user documentation

Dynamic Web application with massive access to parameter setting of JVM tuning case

Server configuration: 8-core CPU, 8G MEM, JDK 1.6.x

Parameter scheme:-server-Xmx3550m-Xms3550m-Xmn1256m-Xss128k-XX:SurvivorRatio=6-XX:MaxPermSize=256m-XX:ParallelGCThreads=8-XX:MaxTenuringThreshold=0-XX:+UseConcMarkSweepGC

Tuning instructions:-Xmx is the same as-Xms to prevent JVM from repeatedly reclaiming memory. -the size of the Xmx is about half of the system memory, which not only makes full use of the system resources, but also gives the system space to run safely. -Xmn1256m sets the size of the younger generation to 1256MB. This value has a great impact on system performance, and Sun officially recommends that the younger generation size be 3can8 of the entire heap. -Xss128k sets up a smaller thread stack to support the creation of more threads, support mass access, and improve system performance. -XX:SurvivorRatio=6 sets the ratio of Eden region to Survivor region in the young generation. The default of the system is 8, and if it is set to 6 according to experience, the ratio of 2 Survivor regions to 1 Eden region is 2:6, and one Survivor area accounts for 1 Eden 8 of the whole young generation. -XX:ParallelGCThreads=8 configures the number of threads in the parallel collector, that is, 8 threads for garbage collection at the same time. This value is generally configured to be equal to the number of CPU. -XX:MaxTenuringThreshold=0 sets the maximum age of garbage (the number of survival times in the younger generation). If set to 0, the younger generation will enter the older generation without going through the Survivor area. For applications with a large number of older generations, the efficiency can be improved. If this value is set to a large value, the younger generation objects will be copied many times in the Survivor area, which can increase the survival time of the younger generation and increase the probability of being recycled in the younger generation. According to the characteristics of dynamic Web applications accessed massively, its memory is either cached to reduce direct access to DB, or quickly reclaimed to support high concurrent mass requests, so it is not meaningful for its memory objects to survive many times in the young generation and can directly enter the old generation. According to the actual application effect, set this value to 0 here. -XX:+UseConcMarkSweepGC sets the older generation to collect concurrently. The goal of CMS (ConcMarkSweepGC) collection is to minimize the pause time of the application, reduce the probability of Full GC occurrence, and use the garbage collection thread concurrent with the application thread to mark and clear the old generation memory, which is suitable for the situation where there are many long life cycle objects in the application.

Internal integration build server for parameter setting

High-performance data processing tools application server configuration: 1 core CPU, 4G MEM, JDK 1.6.X parameter scheme:-server-XX:PermSize=196m-XX:MaxPermSize=196m-Xmn320m-Xms768m-Xmx1024m tuning description:-XX:PermSize=196m-XX:MaxPermSize=196m according to the characteristics of integrated construction, large-scale system compilation may need to load a large number of Java classes into memory, so pre-allocation of a large number of persistent memory is efficient and necessary. -Xmn320m follows the principle that the younger generation is the size of the whole heap. -Xms768m-Xmx1024m can be set according to the approximate heap memory size that the system can bear.

At this point, the study on "how to understand JVM tuning parameters, methods, and tools" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.