Some basic concepts of JVM performance Adjustment

Author Xu permanent

This article lists some of the concepts that I have encountered during my work to adjust WebLogic SP2 SP2 on Solaris 8 after reading relevant materials. It may be helpful to you. This does not mean that I recommend you use a combination of Weblogic and Solaris. On the contrary, I welcome your experiences in Tomcat performance adjustment. After discussing Sun Tech day with Bea's related personnel, I think Bea lacks the vision of open source and free software.

In addition, some of the terms are translated by my own "creations" and I don't know how others translate them. If there is anything inappropriate, I hope to correct it.

Heap is the place where Java programs live their objects, including live objects, dead objects, and remaining memory.

When an object cannot be reached by a pointer to a running program, these objects become "junk".

The JVM heap size determines the time and frequency of VM spending on garbage collection.

The acceptable speed of garbage collection is related to the application. The actual garbage collection time and frequency should be analyzed to adjust.

If the heap size is large, the garbage collection process will be slow, but the frequency will decrease.

If you keep the heap size consistent with the memory size, the full collection will be fast, but it will be more frequent.

The purpose of adjusting the heap size is to minimize the garbage collection time to maximize the processing of customer requests within a specific period of time.

During the benchmark test, to ensure the best performance, set the heap size to a large value to ensure that garbage collection does not appear throughout the benchmark test.

The heap is divided into two regions: the new generation and the old generation.

The new generation is divided into Eden and two living spaces ). Make sure that a piece of space is empty at any time. When garbage collection occurs, the live objects in Eden are copied to the next living space, and objects are copied between living spaces, until the maximum threshold value (aging) is reached, and then copied to the old generation.

Eden is the place where new objects are allocated.

Many objects become spam soon after they are allocated. These objects are called "Infant mortality ."

The longer the object will survive, the longer the collection time is required. Therefore, the collection slows down.

The speed at which your application creates and releases objects determines the garbage collection frequency. Therefore, when programming, you should pay attention to using the Object Buffer, rather than creating a new object.

Most objects are dead in the new generation, so you can effectively adjust the garbage collection. If you can schedule the lifetime of most objects to be less than one collection time, garbage collection is very efficient.

Incorrect "Generation" configuration may cause frequent garbage collection and affect system performance.

If the system spends a lot of time collecting garbage, reduce the heap size.

A complete garbage collection should not exceed 3-5 seconds.

Generally, you should use 80% of the physical memory as the heap size.

Monitor WebLogic performance at maximum workload.
Use the-verbosegc option to measure how much time and resources are used for garbage collection.

Open the detailed information output and redirection of the garbage collection:

% Java-ms64m-mx64m-verbosegc-classpath $ classpath
-Dweblogic. Domain = mydomain-dweblogic. Name = clusterserver1
-Djava. Security. Policy =/BEA/weblogic6x/lib/weblogic. Policy
-Dweblogic. Management. Server = 192.168.0.101: 7001-dweblogic. Management. Username = System
-Dweblogic. Management. Password = systempassword weblogic. Server> logfile.txt

On the Solaris system, run the following command:

Weblogic. Server> server. out 2> & 1

Java hotspot VM options

Standard options have been introduced on various platforms:
Http://java.sun.com/j2se/1.3/docs/tooldocs/win32/java.html
Http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html
Http://java.sun.com/j2se/1.3/docs/tooldocs/linux/java.html

All the options starting with-X are non-standard (not implemented on all VMS) and may be changed without notice in subsequent versions.

Because the-xx option requires special system permissions, it is not recommended to use it at will.

In versions earlier than 1.3.0, the Solaris version of j2sdk has a virtual machine implementation called exact VM (EVM), which has been replaced by Java hotspot VM since 1.3.0.

Java hotspot VM currently has the following-x options:

-Use Training GC for xincgc
-Xnoincgc is not used for training GC (default)
-XX: maxheapfreeratio = <maximum> MAX heap remaining percentage (70 by default)
-X: minheapfreeration = <Minimum> Minimum heap residue percentage (40 by default)
-Xint is only parsed (not JIT compiled)
-XX: + useboundthreads: bind user-level threads (only for Solaris)
-Xmn <size> set the young generation size (Young Generation) (only for 1.4)

Objects are allocated to Eden and die here. When Eden is full, a small collection (minor collection) occurs. Some surviving objects are moved to the old generation. If the old generation needs to be collected, this results in a large collection (major collection), which is relatively slow.

If GC becomes a bottleneck, You need to specify the generation size, check the detailed output of GC, and study the effect of GC parameters on performance.

The collection of old generations adopts the Mark-compact method. Some of them are called permanent generation, which includes all the Reflective Data of the JVM itself ), for example, class and method.

The pause time indicates a brief pause that is displayed by the application due to garbage collection.

Throughput indicates the percentage of the time and total time in which garbage collection is not used for a long period of time.

A small young generation and incremental collection can be used to reduce the pause time, but this is at the cost of throughput.

Footprint is a collection of worker processes, measured by pages and the number of buffered rows. in systems with limited physical memory or many processors, footprint represents scalability.

PROMPTNESS is the time difference between the time when the object dies and the time when the memory becomes available. It must be considered in the distributed system (including RMI.

A large new generation can improve throughput, but sacrifices footprint and promptness.

Solaris footprint can be viewed using the pmap command.

[GC 325407 K-> 83000 K (776768 K), 0.2300771 secs]
[GC 325816 K-> 83372 K (776768 K), 0.2454258 secs]
[Full GC 267628 K-> 83769 K (776768 K), 1.8479984 secs]
The above three lines are the detailed output of GC. We can see two small collections and one large collection. The two numbers before and after the arrow represent the combined length of the GC-lived object. The number in the brackets represents the total space, equal to the heap size minus a living space.

Unless you encounter a pause problem, you can allocate enough memory to the JVM. The default 64 MB is always too small.

Setting the same value for-XMS and-xmx can improve JVM prediction. However, if your choice is incorrect, the JVM will not compensate.

When adding a processor, remember to increase the memory because the allocation can be performed in parallel, while GC is not in parallel.

Newsize and maxnewsize are bound to the low-end and high-end of the new generation length. They are set to the same size as-XMS and-xmx to solve the new generation prediction time.

If the living space is too small, the copy directly enters the old generation. If it is too large, it will be idle.

Unless you encounter a large collection or pause time of transition, allocate enough memory to the new generation. The default maxnewsize (32 MB) is usually too small.

If needed, you can use maxpermsize to increase the maximum permanent generation size.

You can use-XX: + disableexplicitgc to disable direct GC calls.

For large servers, 1.4 of JVM can provide 64-bit addressing capability, provide a larger new generation size, and concurrent collection to reduce the impact of suspension caused by large collection.

Java hotspot client VM is mainly used to reduce the application startup time and memory footprint.

The Java hotspot server VM is similar to the Java hotspot client Vm, but the maximum performance is adjusted. A service application that runs for a long time.

J2se 1.3 For Solaris and Linux is preinstalled with Java hotspot server VM.