"Pile of problems" generated by the wrong heap size

zhaozj2021-02-08  298

Many Java virtual machines provide options to control the size and growth of Java heaps. This article discusses how to properly set the heap size of the minimum value (MS) and the maximum value (MX). The minimum parameter is the starting size of the heap, so setting it and maximum parameters reasonably, which may have a profound impact on your Java application.

MX parameters In most cases, if you think the stack is too small for Java applications, you should set the MX parameter. You can determine if the garbage collection is too frequent by monitoring the output of the JVM running using the Verbosegc parameter on the Java command line. If garbage collection is too frequent, please try to increase the size of the stack. In general, if the application continues to have a short memory error, we recommend that you increase the MX parameter. These errors may be caused by insufficient space in Java piles. Although there is no rule for setting the heap size, the following principles may help:

Do not make the heap grow more than the physical memory of the system. In other words, do not set the MX heap size to greater than [(physical memory) - (operating system and application workspace size)]. Also, if you run multiple JVMs, the sum of all stacks should be smaller than the calculated value. Set the MX parameters if the plug needs to be of the application is greater than half of the total physical memory. In IBM Developer Kit for Windows, Java Technology Edition, version 1.1.8, the default value of the MX parameter is half the total physical memory size. If your application often relies on the Finalizer operation, you need to reduce the size of the MX settings. (Note: We recommend that you avoid this code design.)

There is better support for the Java Server application in IBM Developer Kit for Windows, Java Technology Edition, if you find that you don't have the optimal performance, we recommend that you check the size of the stack. IBM solves this generally existing Java issue by intelligently increasing piles. This technique appeared in IBM Developer Kit for Windows, Java Technology Edition, 1.1.7, and enhanced in IBM Developer Kit for Windows and OS / 2 WARP, Java Technology Edition, 1.1.8 versions. With these JVMs, users have almost no need to set a heap; the initial default value with intelligent growth is generally enough.

Possible Negative Impact Advertising can increase throughput, but will increase the pause time. This is because the collection of large stacks may take a few seconds, but the number of garbage collection will be reduced. Although this cascading response time is critical to the client directly connected to the server, it is worth the increase in the increase in throughput by the deterioration of the server. The heap size is an architecture problem that depends on the application of the application. In IBM Developer Kit for Windows and OS / 2 WARP, Java Technology Edition, 1.1.8, the management of garbage collection and heap growth is based on an active object, so the impact of the pause time is more than the 1.1.7 version. small.

Always pursue the best look for optimal heaps may need to be tested for applications, Java implementations, and operating systems. One way to determine the best heap size range of specific applications is to set MX very large and then run the application with the Verbosegc option. This will generate the output of the heap usage, you can analyze this output so as to make a sensible decision to the heap size. Another method requires more work, but it makes system maintenance easier; this method is to determine the work unit on the server, that is, a complete period of the server to complete work. For example, in a batch system, a work unit is a batch of requests. In a more typical client / server information retrieval cycle, the work unit may be a series of requests submitted together with its login / exit sequence. The process is as follows: The code system.gc () calls the work unit Turn off asynchronous garbage collection and class garbage collection (using -noasyncgc -noclassgc) using a synthetic driver to make the server repeatedly do this work unit use spreadsheet analysis Verbosegc output To determine that the heap size required to complete the average work unit multiplied by the number of work units (for example, the number of users you want the server you want the server to process), and add the basics required to apply the application. The number of heaps, of course, is also the number generated by the "fiction factor" is MX setting. This method needs to complete more work, however, when the actual load of the server changes, the heap size can be adjusted at any time.

MS parameter MS parameters are simpler. If you are worried about the memory utilization and extension overhead, set the MS value to the value of MX. Otherwise, don't set MS. Note that in IBM Developer Kit for Windows and OS / 2 WARP, Java Technology Edition, 1.1.8 versions, the size of the stack can be reduced or increased. Therefore, if the MS is set to a certain value, the stack cannot be reduced to the value below.

Our experience is the best prove that a customer has recently encountered a good example of us, which shows what problems can cause MS and MX's improper settings. The customer's system is a multi-node network connected to the high speed SP base frame. Each node contains 4 CPUs, 2 GB RAM. 10 JVMs run on each node. Each JVM has its own setting, where JVM sets MS to 32MB, set MX to 256MB. A few minutes after starting, the system stops running, and throughput is almost zero. After analyzing the Verbosegc output, we adjusted the heap size, set MS and MX to 300MB. It turns out that each node cannot support more than 20 users. After this change, 125 users can now be easily supported. The initial value of MS will result in excessive garbage collection and slow heap growth, resulting in severe performance. In all cases, it is important to fully understand the features associated with the application and the Java environment used. I hope this short discussion will give you a "pile problem" when you handle your Java application.

转载请注明原文地址:https://www.9cbs.com/read-855.html

New Post(0)