hmgr0152w detected in SystemOut.log: CPU hungry messages < reprint >

The system alerted the!!!!! today. Suddenly people are not good again!!! View the System log,

The error is as follows:

Did not receive adequate CPU time slice. Last known CPU usage time at 14:45:03:180 CST. Inactivity duration was + seconds.

0000047a Coordinatorco W hmgr0152w:cpu starvation detected. Current thread scheduling delay is seconds.

Baidu, the specific reason is:

1. The physical memory is used excessively and the paging is generated.

2. The heap size of the process is too small to cause garbage collection to be frequent or too long to block the execution of other threads.

3. There are too many threads running in the system and too high a load can lead to excessive CPU usage.

Solutions are:

1. Increase physical memory to prevent paging.

2. Optimize the JVM heap memory configuration to optimize garbage collection.

3. Reduce the overall load on the system to an acceptable value.

How to solve these three kinds of schemes?

1. For increasing physical memory, do not know whether it is due to insufficient physical memory, but my machine is 16G of memory, should be enough.

2.JVM heap memory configuration, this can be considered set in the was Management console, the JVM's heap memory value is a bit larger. Specific reference: http://xiaoxinshome.iteye.com/blog/1733212

3. How to reduce the overall load of the system? Is the load too high due to too much request? Can not reduce the number of requests of others AH. For the time being, consider catching the thrown exception and refining the code.

Problem Description:
The system works fine, but many hmgr warning messages are logged in the SystemOut.log.
[10/25/05 16:42:27:635 EDT] 0000047a Coordinatorco W hmgr0152w:cpu starvation detected. Current thread scheduling delay is 9 seconds.

The hmgr0152w information indicates that there is a JVM thread scheduling delay in this process.

The WebSphere application Server High Availability Manager component contains thread scheduling delay detection logic, which periodically initiates a thread that uses this thread to track whether the thread has been dispatched and whether it is running as scheduled. By default, the delay detection thread runs every 30 seconds, and a hmgr0152w message is logged in the log if it is not running for 5 seconds. This message shows the delay or the time lag with which the thread expects to get the CPU and actually get the CPU.

HMGR0152W may even be reported if the CPU resources are available. There are a number of reasons why this scheduler thread could not get the CPU in a timely manner. Here are some common reasons:

1. The physical memory is used excessively and the paging is generated.

2. The heap size of the process is too small to cause garbage collection to be frequent or too long to block the execution of other threads.

3. There are too many threads running in the system and too high a load can lead to excessive CPU usage.

The HMGR0152W warning message tries to tell you that there was a situation that could lead to instability if not corrected in time. You need to analyze why the scheduling thread has delayed and what needs to be done. Here are some common workarounds:

1. Increase physical memory to prevent paging.
2. Optimize the JVM heap memory configuration to optimize garbage collection.
3. Reduce the overall load on the system to an acceptable value.
This message can be ignored if the hmgr0152w information is not frequently reported and the delay is short from the quoted message (for example, less than 20 seconds) and usually no other problem occurs.

Highly available management thread scheduling latency detection can be achieved by configuring one of the following two custom attributes:
1. The Ibm_cs_thread_sched_detect_period parameter determines how long the delay detection thread runs once. The default value is 30 seconds.
2. The Ibm_cs_thread_sched_detect_error parameter determines how long the delay needs to be recorded in the log with this warning message.

These properties are scoped to the core group, and you can configure them as follows:
1. In the admin console, click Server > Core Group > Core Group settings, then select the core group name.
2. Under Other properties, click Customize Properties > New.
3. Enter the attribute name and value.
4. Save the configuration.
5. If you are a network deployment environment, be aware that all nodes are synchronized.
6. Restart all servers where the configuration takes effect on that server.

Although we can increase the thread dispatch detection time with the above two attributes, it is not recommended to make the HMGR0152W warning message completely out of the report. This method is only used to optimize the system to eliminate thread scheduling delays.

hmgr0152w detected in SystemOut.log: CPU hungry messages < reprint >