今天系统报警了！！！！！顿时人又不好了！！！查看系统日志，
报错如下：
Did not receive adequate CPU time slice. Last known CPU usage time at 14:45:03:180 CST. Inactivity duration was 32 seconds.
0000047a CoordinatorCo W HMGR0152W: CPU Starvation detected. Current thread scheduling delay is 32 seconds.
百度了下，具体原因是：
1. 物理内存被过量使用并且产生了分页.
2. 进程的堆大小太小导致垃圾回收频繁或者过长阻塞了其他线程的执行.
3. 系统中运行着太多线程,负载过高可能导致CPU使用过高.
解决方案是：
1. 增加物理内存防止分页.
2. 优化JVM堆内存配置,从而优化垃圾回收.
3. 降低系统的整体负载到一个可以接受的值.
这三种方案，该怎么解决呢？
1.对于增加物理内存，也不知道是不是因为物理内存不够导致的，但我机器是16G内存，应该够的。
2.JVM堆内存配置，这个可以考虑在was管理控制台中设置，将jvm的堆内存值调大一点。具体参考：http://xiaoxinshome.iteye.com/blog/1733212
3.如何降低系统的整体负载呢？请求量过高导致负载也高？也不能降低别人的请求量啊。暂时可以考虑把抛出的异常捕获，精简代码。
问题描述:
系统工作正常,但是在SystemOut.log中记录了很多HMGR的警告信息。
[10/25/05 16:42:27:635 EDT] 0000047a CoordinatorCo W HMGR0152W: CPU Starvation detected. Current thread scheduling delay is 9 seconds.
HMGR0152W信息报出说明这个进程中存在JVM线程调度延迟。
WebSphere Application Server高可用管理器组件中包含线程调度延迟检测逻辑，它会周期性的启动一个线程， 用这个线程去跟踪是否线程已经被分派，是否按照计划运行。默认情况下,延迟检测线程每30秒钟运行一次, 如果超过计划5秒钟没有运行就会在日志中记录一条HMGR0152W消息。这条消息显示了延迟的时间或者与该线程期望得到CPU和实际得到CPU的时间差。
HMGR0152W甚至可能在CPU资源可用的情况下报出。有很多原因可能导致这个调度线程不能以适时的方式获得CPU.下面是一些常见的原因:
1. 物理内存被过量使用并且产生了分页.
2. 进程的堆大小太小导致垃圾回收频繁或者过长阻塞了其他线程的执行.
3. 系统中运行着太多线程,负载过高可能导致CPU使用过高.
HMGR0152W警告信息试图告诉您出现了一个如果不及时修正可能导致不稳定的情况.您需要分析为什么调度线程发生了延迟,需要采取哪些措施.下面是一些常用的解决方法:
1. 增加物理内存防止分页.
2. 优化JVM堆内存配置,从而优化垃圾回收.
3. 降低系统的整体负载到一个可以接受的值.
如果HMGR0152W信息不是经常报出,并且从报出的消息看延迟很短(例如小于20秒), 通常不会有其他问题发生,这个时候这个消息可以被忽略.
高可用管理线程调度延迟检测可以通过配置下面两个定制属性中的一个来实现:
1. IBM_CS_THREAD_SCHED_DETECT_PERIOD 参数决定延迟检测线程多长时间运行一次.默认值是30秒.
2. IBM_CS_THREAD_SCHED_DETECT_ERROR 参数决定多长时间的延迟需要被用这个警告信息记录在日志中.
这些属性辖域在核心组上,您可以按照如下方法配置:
1. 在管理控制台中, 点击服务器 > 核心组 > 核心组设置, 然后选择核心组名字.
2. 在其它属性下, 点击定制属性 > 新建.
3. 输入属性名和值.
4. 保存配置.
5. 如果是网络部署环境, 请注意同步所有节点.
6. 重新启动所有的服务器是该配置在该服务器上生效.
虽然我们可以用上面两个属性增加线程调度检测时间, 但是不建议通过它们使HMGR0152W警告消息完全不再报出. 这个方法只是用于优化系统消除线程调度延迟.
相关文章：
was日志报检测到cpu饥饿
http://xjsunjie.blog.51cto.com/999372/1294089/
如何分析websphere中间件生成的javacore文件
http://blog.sina.com.cn/s/blog_61cd89f60102eeo0.html