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

JVM optimization configuration guidance is what, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

This article gives you a brief introduction to the concept of optimal configuration of JVM. In general, it is not recommended to manually configure JVM parameters to adjust performance without any statistics and analysis, because above JVM5, algorithms have been made to automatically configure appropriate parameters according to the machine and OS, which can basically meet most of the situations.

Optimized configuration of JVM

The first thing to note here is that the JVM mentioned here is the HotSpotJVM5 and above version of Sun. There are many ways to optimize performance in applications, including Cache, multithreading, various algorithms and so on. Generally speaking, it is not recommended to manually configure JVM parameters to adjust performance without any statistics and analysis, because algorithms have been made above JVM5 to automatically configure appropriate parameters according to the situation of the machine and OS, which can basically meet most of the situations. Of course, this automatic adaptation is only a general way, if you really want to achieve *. Then it is still necessary to manually configure various parameter settings according to the actual usage to improve performance.

The part where JVM can have an impact on performance is memory management. Since jdk1.5, there have been many improvements in memory management and allocation. Several basic concepts and parameters of memory allocation and management are described:

◆ JavaHotspotMode:

For server and client, if not configured, JVM will automatically select the mode according to the hardware configuration of the application server. Server mode starts slowly, but the runtime speed is optimized, and client starts faster, but the runtime response is not optimized as server mode, so it is suitable for personal PC service development and testing.

◆ GarbageCollectorPolicy:

Three kinds of GC are already available at Jdk1.5, and in addition to the original serial GC (SerialGC), two new GC:ParallelGC and ConcMarkSweepGC are also provided. ParallelGC adopts multi-thread parallel management and collection of garbage objects, which improves the recovery efficiency and the throughput of the server, and is suitable for multi-processor servers.

◆ ConcMarkSweepGC

The concurrent mode is used to manage and collect garbage objects to reduce the response pause time caused by garbage collection. Here we talk about the difference between concurrency and parallelism. Concurrency refers to multiple processes performing garbage collection in parallel, so you can make good use of multiprocessors, while parallelism means that applications can work concurrently with garbage collection threads without pausing. Serial GC is suitable for small applications and single-processor systems (high efficiency without multithreaded interaction), while the latter two are suitable for large-scale systems.

The way to use it is to add-XX:+UseParallelGC and other methods to the parameter configuration.

For this part of the JVM optimization configuration, there are many examples on the Internet for reference, but the final use of which kind of GC should be analyzed and selected according to the specific situation.

Heap:

OOM's various experiences have shown every architect and developer the importance of understanding Heap. OOM is already the critical point of Heap and has to be noticed, but the potential impact of Heap on performance has not been paid attention to. However, like GC configuration, rashly modifying Heap configuration without careful analysis and research on usage may be counterproductive. Here let's take a look at some concepts of Heap and its impact on performance.

The Heap available to our applications is restricted by three factors: the data processing model (32-bit or 64-bit operating system), the total amount of system virtual memory and the total amount of physical memory of the system. First of all, the size of Heap cannot exceed the process addressing range of different operating systems. At present, the limit of most systems is 4G, Windows is usually 2G, Linux is usually 3G. The virtual memory of the system is also the basis for allocation, first of all, it can not be exceeded, and then because the operating system supports the hard disk to do part of the virtual memory, if the setting is too large, it is bound to have an impact on the application response. It is also important to consider that the total resources consumed by running multiple Java virtual machines on the same server cannot exceed the available resources. As in the previous OOM analysis, in fact, due to the limitations of OS's data processing model, the machine's own hardware memory resources and virtual memory resources do not necessarily match, so how to adjust the resource allocation under the limited resources is particularly important for applications.

There are several parameter settings about Heap in JVM optimized configuration:

After talking about the limited resources of Heap, let's take a look at how to change the allocation of JVM to Heap through configuration. The following is mainly about the allocation of JavaHeap, so after applying for JavaHeap, the remaining available resources will be used to NativeHeap.

The size of the Xms:javaheap at initialization. The default is 1x64 of the machine's physical memory. This is mainly based on the resources consumed when the application starts. Less allocation will reduce the startup speed, and too much allocation will be wasted.

The * value of Xmx:javaheap, which defaults to 1G of the physical memory of the machine.

This value determines the most available JavaHeapMemory. Too little allocation will cause problems with OOM when the application needs a lot of memory for caching or 00:00 objects. If the allocation is too large, it will result in the second type of OOM mentioned above. So how to configure or according to the running process of analysis and calculation to determine, if not sure or use the default configuration.

The space size of the new generation of Xmn:javaheap.

In the GC model, according to the length of the life cycle of the object, the design of memory generation is produced: youth (internal is also divided into three parts, similar to the role of overall partition, the proportion can be set through configuration), old age, persistent generation. The management and recycling strategies of each generation are different, the most active is the youth, and the memory allocation and management efficiency of this part is also *. In general, the application for memory is first applied in the new generation, and when there is not enough memory, the new generation will be sorted out, and when the memory still cannot meet the application, some objects with a longer life cycle will be moved to the old age.

This kind of arrangement and movement will consume resources and reduce the response ability of the system, so if the youth setting is too small, it will be arranged and moved frequently, which will affect the performance. Whether it is better to set the younger generation as big as possible, in fact, the younger generation uses the replication collection algorithm, which must stop all application threads. The server thread switching time will become the bottleneck of the application response (of course, there is no such problem). In the old days, serial tag collection was adopted, and concurrent collection can reduce the impact on the application.

Xss: thread stack * value. Allow more virtual memory space addresses to be used by JavaHeap. The above introduces some theoretical knowledge about the optimal configuration of JVM. Let's take a look at a few examples.

Here are a few examples mentioned in sun's performance optimization white paper:

1. Tuning for throughput. Machine configuration: 4G memory, 32 thread concurrency.

Java-Xmx3800m-Xms3800m-Xmn2g-Xss128k-XX:+UseParallelGC-XX:ParallelGCThreads=20

-Xmx3800m-Xms3800m is configured with * * JavaHeap to make full use of system memory.

-Xmn2g creates enough youth (which can be recycled in parallel) to make full use of system memory to prevent short-term objects from being copied to the old age.

-Xss128 reduces the default thread stack size and provides more address space for processing virtual memory to be used by processes.

-XX:+UseParallelGC uses parallel garbage collector to collect the memory of the younger generation to improve efficiency.

-XX:ParallelGCThreads=20 reduces garbage collection threads. By default, the number of concurrent threads supported by the server is the same as that supported by the server, and often does not need to be configured to a * * value.

2. Try to collect the old age in parallel.

Java-Xmx3550m-Xms3550m-Xmn2g-Xss128k-XX:+UseParallelGC-XX:ParallelGCThreads=20-XX:+UseParallelOldGC

-Xmx3550m-Xms3550m memory allocation is reduced because ParallelOldGC increases the demand for NativeHeap, so you need to reduce JavaHeap to meet the demand.

-XX:+UseParallelOldGC adopts the strategy of concurrent collection in the old era, which can improve the efficiency of collection.

3. Improve throughput and reduce application pause time

Java-Xmx3550m-Xms3550m-Xmn2g-Xss128k-XX:ParallelGCThreads=20-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:SurvivorRatio=8-XX:TargetSurvivorRatio=90-XX:MaxTenuringThreshold=31

-XX:+UseConcMarkSweepGC-XX:+UseParNewGC chooses the concurrent tag exchange collector, which can perform collection operations concurrently and reduce the application stop time. At the same time, it is also a parallel processing mode, which can effectively make use of the multi-process processing of multiprocessor systems.

-XX:SurvivorRatio=8-XX:MaxTenuringThreshold=31 indicates that in the youth, the ratio of Eden to Survivor, the setting increases the size of the Survivor, and the larger the survivor space allows short-term objects to die out in the younger generation as much as possible.

-XX:TargetSurvivorRatio=90 allows 90% of the space to be occupied, exceeding the default of 50%, increasing the utilization of survivor.

There are many similar examples on the Internet, but they are not listed here. Whether to take your own configuration to replace the default configuration or to analyze and configure it according to the usage of the virtual machine.

After reading the above, have you mastered the method of JVM optimization configuration guidance? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.