4.3.1 Types of resources that can be monitored
The resource depletion monitoring functionality can monitor seven types of resources. You can choose to monitor all resources or the necessary resources only. However, there are resources that cannot be monitored depend on the OS used. Furthermore, in the batch server, you cannot monitor the HTTP request pending queue and the number of sessions.
The details of each resource are explained below:
-
Monitoring the memory involves monitoring the heap memory area in the JavaVM. Symptoms that trigger Full GC can be detected by monitoring memory usage. The monitoring results can also be used to tune the heap and memory sizes.
KDJE34500-W is output when the set threshold value is exceeded.
- Tip
-
Although this functionality monitors memory usage, Full GC does not always occur when the percentage of memory usage has become close to 100%. The monitoring results are used to detect symptoms that are highly likely to trigger Full GC.
-
Monitoring the file descriptor
Monitoring the file descriptor involves monitoring the file descriptors that are open in the server processes. Monitoring the number of file descriptors helps to detect the depletion of file descriptors that can be used in the processing of server allocated to the system, and detect the depletion before the number of file descriptors that are requested in the estimate, is reached.
KDJE34520-W is output when the set threshold value is reached.
File descriptors cannot be monitored in Windows and AIX.
-
Monitoring the threads involves monitoring the number of threads generated during the processing of server. By monitoring the number of threads that are generated, you can detect whether the number of threads that can be generated during the process of the server allocated to the system has exceeded before the number of threads requested in the estimate is reached.
KDJE34540-W is output when the set threshold value is reached.
Thread monitoring cannot be used in Linux.
-
Monitoring the thread dump involves monitoring the number of thread dump files that are output when monitoring the cjdumpsv command, or the J2EE application execution time, in a server. By monitoring the number of thread dump files; you can detect before the maximum number of files is reached.
Note that if you specify the environment variable JAVACOREDIR, this functionality monitors the total number of files of the thread dump of both the directories; the directory specified in the environment variable JAVACOREDIR and the default output destination directory (in Windows: work-directory\ejb\server-name and in UNIX: work-directory/ejb/server-name). If the path specified in the environment variable JAVACOREDIR is not in the directory and the file list cannot be acquired, only the number of files of the default output destination are monitored.
KDJE34580-W is output when the set threshold value is reached. KDJE34581-E is output when the maximum value is reached.
For details on monitoring the J2EE application during runtime, see 5.3 Monitoring and Canceling a J2EE Application During Runtime.
- Notes
-
The process of monitoring the thread dump has a load in proportion to the number of files and directories of the directory specified in the environment variable JAVACOREDIR and the default output destination directory. Therefore, set up the monitoring interval of the thread dump for a longer time or do not allocate unnecessary files to the directories.
-
Monitoring the HTTP requests queue
Monitoring the HTTP requests queue involves monitoring the number of requests in the pending queue in the synchronous thread control of a Web application. The pending queues to be monitored are the pending queue of each Web application and the default pending queue. You can monitor the queues on the J2EE server or the Web application. Monitoring the pending queue for each Web application and the default pending queue of the HTTP requests helps to detect the queue status before the requests exceed the size of these pending queues.
However, when the specified size of the pending queue for each Web application and the default pending queue are '0', the HTTP requests queue is not monitored.
The initial value specified for the threshold value does not change even when the size of the pending queue for each Web application changes dynamically.
KDJE34621-W is output when the set threshold value is reached.
For the number of concurrently executed threads, see 2.15 Controlling the number of concurrently executing threads in the Web application in the uCosminexus Application Server Web Container Functionality Guide.
Use the statistics collection functionality to monitor requests in the pending queue for URL groups. For how to set up the threshold value using the statistics collection functionality, see 3.4.1 Monitoring target for which threshold value can be set.
-
Monitoring the number of sessions
Monitoring the number of sessions involves monitoring the number of sessions that are generated in a Web application. Monitoring the number of sessions can detect any increase in the number of sessions.
The number of sessions, however, is not monitored when '0' is specified for the number of sessions that can be created during the setup of number of sessions.
KDJE34640-W is output when the set threshold value is reached.
-
Monitoring the connection pool
Monitoring the connection pool involves monitoring the usage of the connection pool. This can detect the depletion of connections before it occurs and hence, can be used to tune the connection pool.
The usage of connection cannot be monitored when connection pool is inactive. Moreover, when the maximum value of the connection pool is infinite, the usage of the connection pool can be monitored but the management event is not notified.
KDJE34660-W is output when the set threshold value is exceeded. KDJE34661-W is output when the maximum number is reached.
For connection pool, see 3.14.1 Connection pooling in the uCosminexus Application Server Common Container Functionality Guide.