JVM Monitoring
JVM monitoring displays the memory and thread metrics of the JVM running environment based on Java applications. You can monitor metric trends in real time for performance analysis.
On the Memory and Thread tab pages, you can respectively view the memory and thread graphs to quickly locate problems such as memory leakage and thread exceptions.
Memory Graphs
As shown in Figure 1, in a selected time range, the trends of the maximum, committed, and used memory in different JVM memory spaces (such as the total memory, heap memory, and non-heap memory spaces) of an instance are displayed. In addition, the garbage collection (GC) duration and times are also displayed.
JVM memory
JVM memory consists of heap and non-heap memory.
- Heap memory: A heap is the data area where the JVM is running. It allocates memory for all instances and arrays. Heap memory of objects is reclaimed by an automatic memory management system called garbage collector. Heap space consists of eden space, survivor space, and tenured space.
- Non-heap memory: Memory (excluding heap memory) managed by JVM. Non-heap space consists of code cache and permanent space (or meta space).
Java heap is the main area managed by the garbage collector. It is also called garbage collection heap. GC mode includes full GC and minor GC.
Space Name |
Description |
---|---|
Eden space |
Initially allocates memory from the thread pool to most objects. |
Survivor space |
Stores the eden space's objects that are not reclaimed during GC. |
Tenured space |
Maintains objects that have been stored in the survivor space for a period of time. |
Code cache |
Compiles and stores local code. |
Permanent space |
Stores static data of VMs, for example, classes and method objects. |
Meta space |
Stores local class metadata. In versions later than Java 8, permanent space is replaced by meta space. |
Direct Buffer |
Resource usage of the direct buffer is monitored. |
Full GC |
Indicates the GC performed in the entire heap space (covering young-, old-, and permanent-generation spaces) when the memory space is still insufficient after memory reclamation. |
Minor GC |
Indicates the GC performed in the young-generation space (including eden and survivor spaces) when the allocated memory is insufficient. |
JVM collects garbage based on generations. JVM heap space is divided into old- and young-generation spaces. More than 90% objects that exist only for a short period of time are stored in the young-generation space, whereas objects that have long life cycles are stored in the old-generation space. Young-generation space is further divided into eden space and two survivor spaces. New objects are initially allocated to the eden space. The survivor spaces are used as the buffer between eden space and tenured space. Objects that are survived after several rounds of GC in the survivor spaces are then transferred to the old-generation space, as shown in Figure 2.
There are two survivor spaces, which are represented by from and to pointers. The to pointer points to the empty survivor space.
Thread Graphs
As shown in Figure 3, in a selected time range, the trends of new, runnable, blocked, and waiting threads are displayed.
Thread Name |
Description |
---|---|
Total threads |
Both active and standby threads are included. Sticky threads and dedicated threads become standby threads after being executed. |
Deadlock threads |
When two or more threads encounter resource conflicts or the communication between them is abnormal, the system enters the deadlock state. |
New threads |
Number of threads that are newly created. |
Runnable threads |
Number of threads that can run. |
Blocked threads |
Number of threads that are blocked. |
Waiting threads |
Number of threads that are in the waiting state. |
Timed waiting threads |
Number of threads that are waiting for another thread to perform an action for a specified waiting time. |
Terminated threads |
Number of threads that are terminated. |
Max connections |
Maximum number of connections that are supported by Tomcat. |
Current connections |
Number of connections that are being occupied on Tomcat. |
Max threads |
Maximum number of threads that can be executed on Tomcat. |
Current threads |
Number of threads that are being executed on Tomcat. |
Busy threads |
Number of threads executed on Tomcat for processing tasks. |
Adding a Threshold Rule
You can add threshold rules for all JVM memory and thread metrics. When the rules are met, alarms are reported, altering you to risks.
- On the JVM Monitoring page, select an application in the upper left corner, and then select an instance.
- In the trend graph of a memory or thread metric on the right, set a threshold rule. Specifically, click Add Threshold Rule on the top of the trend graph.
- Set rule parameters and click Submit, as shown in the following figure. If you want to receive alarm notifications, select Yes when setting Send Notification and then select a topic.
Description of the Add For Service parameter:
- If this parameter is set to Yes, the threshold rule is applied to the entire service.
- If this parameter is set to No, the threshold rule is applied to a single instance.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot