Help Center > > User Guide> JVM Monitoring

JVM Monitoring

Updated at: Jan 05, 2021 GMT+08:00

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.

Figure 1 Memory graphs

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.

Table 1 Memory spaces

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.

Figure 2 Memory spaces

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.

Figure 3 Thread graphs

Table 2 Threads

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.

  1. On the JVM Monitoring page, select an application in the upper left corner, and then select an instance.
  2. 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.

  3. 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.

Did you find this page helpful?

Submit successfully!

Thank you for your feedback. Your feedback helps make our documentation better.

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?







Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel