利用CPU监控诊断WAS性能

使用 WAS做为应用服务器，如果感觉用户交易响应时间很长，可以通过观察CPU资源的使用来判断问题。

  如果CPU使用不高，说明所有请求都在等待，可以断定是系统的某一小部分造成了瓶颈。比如，线程池的数量开的太小，导致所有的请求都在排队等待进入线程池，因为没有可用的线程使用，所以这个交易请求一直在排队，导致交易响应时间很长。如果数据库连接池开的太小，也会有同样的表现。

  如果CPU使用很高，对于这种情况，比较复杂。

　可能的根源之一是硬件资源不够。包括CPU处理能力过低和物理内存不足。CPU处理能力不足一般表现为长时间占用较多CPU,物理内存不足导致内存分页或者频繁的GC,增加了处理器的负担。

　根源之二是应用系统中产生了多个大对象。我们经常遇到如下的例子，如果一个报表系统运行在WAS里，用户经常抱怨系统的响应时间太长，反应太慢的情况。问题的根本原因是报表系统会产生一些大对象，而这个大对象的数值如果超过2M, JVM一定要在有限的空间里为对象找到连续的空间。如果JVM为这个对象找不到连续的空间，就会对整个内存空间进行整理，如果大对象比较多，由于JVM对内存空间的频繁整理会对系统的性能有着急剧的影响。造成系统的响应时间非常慢，所以应用程序应尽量避免产生大对象，或者用一个链表的结构来表达大对象，本质上把一个大对象拆成几个可以联接的小对象，让JVM可以很容易的分配内存空间。大对象的判断，可以通过启用GC日志，模拟用户操作后，分析GC日志中申请分配的空间大小来辨别。如下，申请的对象达到了5M.
X#~:yYf0
Cl!_&Z6~P0　<AF[110]: Allocation Failure. need 5242896 bytes, 132793 ms since last AF>
2X7BjBMo^0　<AF[110]: managing allocation failure, action=2 (100847704/1637153280)>ITPUB个人空间7P?qL(S-MZ
  　<GC(129): GC cycle started Sun Nov 02 16:15:35 2008ITPUB个人空间j/B'ep/B:H-vl.I
  　<GC(129): freed 179760128 bytes, 17% free (280607832/1637153280), in 1212 ms>
F[ Z[
wE[0  　<GC(129): mark: 1154 ms, sweep: 58 ms, compact: 0 ms>
@hFXH)Y&n} oi|0  　<GC(129): refs: soft 0 (age >= 32), weak 0, final 518, phantom 0>ITPUB个人空间'^R@mW/O4N1pw
　<AF[110]: completed in 1213 ms>

　根源之三是程序算法有问题。 解决思路如下：用性能分析器，如RAD或JProfiler, 对运行环境进行分析，分析哪个类甚至于哪个函数消耗了这么多的CPU，并找到相应的解决方案。