JVM load quantification and optimization method

Abstract

The invention discloses a JVM load quantification and optimization method. The method comprises the steps that when a garbage collector executes GC, obtaining GC data through GC callback; calculatinga measurement index according to the GC data; and executing a corresponding operation and maintenance operation according to the calculated value of the measurement index. According to the JVM load quantification and optimization method, the measurement index for measuring the JVM load is constructed through the GC data, and related operation and maintenance operation is performed according to themeasurement index. On one hand, the real condition of the JVM load can be reflected more accurately through the measurement index constructed by the GC data, and meanwhile, GC is certainly generatedwhen the JVM load is changed, so that the JVM load condition is evaluated more timely through the GC callback data.

Description

technical field [0001] The invention relates to a JVM load quantification and optimization method. Background technique [0002] The quantification of JVM (Java Virtual Machine, Java virtual machine) load has always been a technical problem. It is rare to see Java software products on the market that include automatic load quantification mechanisms in built-in functions. In the prior art, the memory usage rate is generally obtained by polling to represent the level of JVM load. This approach has the following drawbacks: [0003] 1. Polling to obtain memory usage, the response is not timely enough: JVM load changes are at the millisecond level in the time dimension, but polling to obtain memory usage generally only reaches the second level, and second-level polling is Insufficient response to sudden load changes. But if you do millisecond-level polling, the overall performance is poor. [0004] 2. Due to the role of the GC (Garbage Collection, garbage collection) mechanis...

AI Technical Summary

Problems solved by technology

[0003] 1. Polling to obtain memory usage, the response is not timely enough: JVM load changes are at the millisecond level in the time dimension, but polling to obtain memory usage generally only reaches the second level, and second-level polling is Insufficient response when the load changes drastically

But if you do millisecond-level polling, the overall performance is poor

[0004] 2. Due to the role of the GC (Garbage Collection, garbage collection) mechanism of the JVM (when the JVM memory is almost full, the system will automatically trigger garbage collection, clear some useless Java objects, and reclaim memory space), it is characterized by memory usage The level of JVM load does not reflect the real load of the JVM well

When the memory usage rate is high, it is likely that the Java objects in the JVM can be effectively recycled by the GC. In this case, the real situation of the JVM load is not high. If it is directly represented by the memory usage rate, it will be misjudged as high Load, and then make a series of unnecessary response measures, affecting the user experience (such as frequently sending risk warnings, frequently restricting user requests, etc.)

When the memory usage rate is not very high, it is possible that the active threads in the JVM are rapidly creating Java objects. According to the life cycle of Java objects, such objects are generally difficult to be effectively recycled by the GC in a short period of time. As a result, the JVM quickly enters an overloaded state. In this case, the real situation of the JVM load is very high. If it is directly represented by the memory usage rate, it will be misjudged as a low-to-medium load, so it misses a good opportunity to take effective operation and maintenance measures. affect the stable operation of the system

Images