High GC activity generally has a negative effect on CPU usage.There are three possible reasons for this: the young generation is too small, there's a high churn rate, or there's too much transactional memory usage. If the utilization of the old generation fluctuates greatly without rising after GC, then objects are being copied unnecessarily from the young generation to the old generation.A high number of young collections can be the cause of a response-time problem and of a growing old generation (because the young generation cannot cope with the quantity of objects anymore).
The higher the number, the more objects are allocated. The number of young-generation collections provides information on the churn rate (the rate of object allocations).In this case, a memory heap analysis is necessary. If overall memory utilization is increasing continuously despite garbage collection, there is a memory leak, which will inevitably lead to an out-of-memory error.
Memory shortage is the number-one reason for increased GC activity. Utilization of the different memory pools (Eden, survivor, and old).Based on this we need to monitor the following: We therefore need to correlate the suspensions caused by garbage collection with the application's response time. Only GC suspensions affect response time directly, and a GC can also run concurrent to the application. However, monitoring memory utilization and garbage collection times is not enough, as these two elements alone do not tell us if the application response time is affected by garbage collection. Consequently, we need to monitor the impact of garbage collection on response time and memory usage to ensure both stability and performance. Memory shortage is often the cause of instability and unresponsiveness in a Java applications. Each JVM vendor includes its own monitoring tools, and there are numerous commercial tools available that offer additional functionality. The Oracle JRockit JDK includes JRockit Mission Control and the verbose:gc flag of the JVM.
The Oracle JDK also includes jStat, which enables the monitoring of memory usage and garbage-collector activity from the console, and Java VisualVM (or jvisualvm), which provides rudimentary memory analyzes and a profiler. Since Java 5, the standard JDK monitoring tool has been JConsole. Finally, if configuration changes alone are not enough we must analyze the allocation patterns and memory usage itself. The goal of every configuration change must be to decrease that impact. If garbage collection has a negative impact on response time, our goal must be to optimize the configuration. To identify memory-caused instability or excessive garbage collection we first need to monitor our Java application with appropriate tools. Memory shortages and leaks often lead to instability. It is equally important to ensure the stability of the application. The goal of any Java memory analysis is to optimize garbage collection (GC) in such a way that its impact on application response time or CPU usage is minimized.
0 kommentar(er)
