1.Websphere JVM相关问题诊断：
由JVM引起的Websphere问题主要有应用服务器宕机和性能下降，JVM相关问题的特征如下：
(1).Websphere应用服务器停止响应：
a.Websphere服务器宕机。
b.Websphere进程挂起。
c.JVM内存溢出。
(2).性能下降：
JVM进程号(process Id)不停地改变。
2.诊断JVM相关问题所需文件：
(1).核心文件(Core files)：
a.进程快照或者系统的核心文件。
b.完整的JVM内存快照等。
注意：文件非常庞大，需要ISA(IBM Support Assistant)的日志分析工具解析。
(2).javacore文件：
a.正在运行的java进程的快照。
b.Websphere应用服务器发生错误时自动生成的文件。
存储路径为：<WAS_install_root>/profiles/<profile>。
(3).JVM详细的垃圾回收器日志。
(4).JVM堆快照。
3.JVM垃圾回收器日志：
(1).设置Websphere中JVM垃圾回收器步骤：
在Websphere管理控制窗口点击：Servers->Application servers-><server_name>->Java and Process Management ->Process Definition->Java Virtual Machine, 勾选” Verbose Garbage Collection ”复选框，重启Websphere即可。
(2).JVM详细的垃圾回收器日志写在系统错误日志文件中(native_stderr)。
(3).在产品发布以后，推荐将Websphere的JVM垃圾回收器日志打开，它消耗资源非常的少。
4.JVM关于堆的相关参数设置：
(1).JVM最大的堆内存大小(maximum heap, -Xmx)：
设置合理的最大堆有助于JVM优化性能，最大堆越大，JVM垃圾回收器收集一次垃圾花费的时间越长；最大堆越小，JVM垃圾回收器运行很频繁。
合理的最大堆应该是稍微大于当程序运行稳定时所需的最大堆容量。
(2).JVM初始化堆内存大小(minimum heap,-Xms)：
设置合理的最小堆可以提高Websphere应用服务器的启动时间。
最小堆太小，JVM可能在服务器启动重新过程不断调整重新设置最小堆，从而影响启动速度。
最小堆太大，垃圾回收器需要回收较大的内存空间，容易产生内存碎片。同时由于初始堆内存太大，分配堆内存花费的时间比较大，程序响应速度慢。
5.JVM垃圾回收器性能指标：
垃圾回收器是JVM中引起内存性能瓶颈的主要原因，JVM的垃圾回收器性能指标：
(1).吞吐量(Throughput)：
指JVM没有花费在垃圾回收器上的百分比，即JVM在处理程序运行所花费时间占整个JVM运行时间的百分比。
(2).暂停(Pauses)：
指JVM垃圾回收器运行时间的百分比，即因为JVM垃圾回收器运行而暂停应用程序处理时间占整个JVM运行时间的百分比。
6.Websphere中JVM垃圾回收器的回收策略(GC policy)：
(1). –-Xgcpolicy:optthruput
jvm调优参数让JVM尽可能花最多时间处理应用程序，尽量减少垃圾回收器的运行时间。
(2). –-Xgcpolicy:optavgpause
让JVM尽可能多回收垃圾，当不可预知的情况发生时，应用程序响应时间比较快。
(3). –-Xgcpolicy:gencon
适合于应用程序需要大量分配堆内存给短存活周期对象的情况，垃圾回收器使用分代复制算法，让垃圾回收器尽快回收已经死亡的年老代对象。
(4). –-Xgcpolicy:subpool
适合于应用程序在多个线程中频繁给大对象分配堆内存的情况。
7.通过JVM线程快照诊断进程挂起问题：
当怀疑JVM进程挂起时，以下的方法可以帮助诊断JVM进程挂起相关问题：
(1).收集JVM线程快照或者JavaCore文件：
Websphere默认是打开的，也可以在命令行(linux)中通过”kill -3”向Websphere发送信号产生JVM线程快照和JavaCore相关文件。
(2).当进程挂起时，每个几分钟收集一下JVM线程快照：
当进程挂起产生时，需要每个几分钟收集一下JVM线程快照，以帮助分析进程内部的运行情况。
(3).手动或者通过ISA的线程分析器查看JVM线程快照文件：
a.检查是否有线程死锁产生。
b.检查所有发送请求后等待响应的线程运行情况。
8. 通过JVM JavaCore文件诊断进程挂起问题：
查看javacore文件主要根据线程的运行状态进行相应的问题诊断：
(1).线程处于阻塞状态：
a.无法访问的资源，或者逻辑错误的线程同步都有可能导致线程被阻塞。
b.死锁也可能导致线程被阻塞。
(2).线程处于运行状态：
a.通过多个javacore文件检查方法的调用堆栈。
b.如果一个方法内产生很多线程，有可能方法的循环逻辑有问题。
(3).线程处于等待状态：
线程可能因为等待资源被挂起。
9.Websphere中线程挂起诊断：
Websphere中包含了探测线程挂起的功能，它不会去杀掉挂起的线程，只会通过以下3种方式通知线程挂起：
(1).向JMX发送JMX通知，通过第3方的工具捕获JMX事件处理线程挂起。
(2).通过线程池流量监测系统向PMI客户发送线程挂起通知。
(3).向Websphere的SystemOut.log日志中写线程挂起的消息，格式如下：
[4/17/04 11:51:30:243 EST] 2d757854 ThreadMonitor W CWWSR0605W:      Thread Servlet.Engine.Transports : 0 has been active for 14,198    milliseconds and may be hung. There are 1 threads in total in the server that    may be hung.
(4).当之前一个线程被报告为挂起，如果线程又正常运行后，Websphere会向SystemOut.log日志中写线程正常运行的消息，格式如下：
[2/17/04 11:51:47:210 EST] 76e0b856 ThreadMonitor W WSVR0606W: Thread Servlet.En
gine.Transports : 0 was previously reported to be hung      but has completed. It was active for approximately 31,166 milliseconds. There are 0 threads in total in the server that still may be hung.
(5).Websphere的监控器对于线程挂起的判定和警告处理可以智能调节，即如果前一次产生的线程挂起告警后来证实是正常运行的，则Websphere会相应调整判定条件。
10.Websphere宕机问题症状和常见原因：
Websphere宕机时的主要表现为：Websphere进程因为java异常或者操作系统本地信号而终止运行。
Websphere宕机的常见原因：
(1).JVM内存溢出异常。
(2).JVM栈溢出。
(3).无法预知的其他异常情况，如磁盘空间不足等。
(4).JVM性能优化失败，如由JIT引起的问题。
(5).Java本地方法调用(JNI)产生错误，或者类库产生问题。
(6).JVM调用本地机器码执行时，产生内存段冲突。
11.Websphere宕机问题诊断：
(1).Core文件：
a.进程快照和系统的核心文件。
b.二进制格式的完整的虚拟内存快照文件。
注意：core文件可能非常大，另外有些是二进制格式不可读，因此需要使用ISA的日志分析工具解析。
(2).JavaCore文件：
Java的内存快照文件和线程快照文件。
(3).为JVM配置–Xdump 参数：
可以指定产生系统快照、java快照和对内存快照。
13.Websphere内存溢出常见原因：
内存溢出产生是指JVM没有足够的内存空间为对象分配内存，常见原因如下：
(1).JVM的java堆太小。
(2).JVM中内存空间是够用的，但是都是零散的，即没有一块的容量可以符合新产生对象的堆内存需求(在JDK1.4.2及其以前版本中很常见)。
(3).java代码导致的JVM内存泄漏。
(4).机器本身内存不够用。
14.内存溢出问题诊断方法：
(1).首先分析javacore文件中内存相关的问题。
a.检查堆内存大小信息。
b.查看内存溢出异常栈。
(2).分析垃圾回收器产生的文件和堆信息：
a.检查垃圾回收器的详细日志。
b.查看对内存快照。
15.Websphere内存溢出症状：
(1).JVM堆内存经常以恒定的增长速度不停的增长，直到达到最大堆内存值。
(2).JVM堆内存从来没有处于一个稳定的状态。
16.Websphere内存溢出诊断和解决方法：
(1).在Websphere管理控制台窗口增大JVM最大堆内存值(Xmx)，方法如下：
在Websphere管理控制台窗口点击：Servers -> Application Servers -> server-> Java and Process Management -> Process Definition -> Java  Virtual Machine -> Maximum heap size。
(2).检查JVM详细的垃圾回收器日志，审查内存分配失败原因：
a.到因为内存溢出引起的内存分配失败。
b.检查被分配堆内存对象的大小。
c.确认JVM的堆内存大小。
d.查看JVM堆内存空闲利用率(JVM堆没有被分配使用总整个JVM堆的百分比)。
(3).检查之前类似的内存分配失败问题：
a.如果持续产生内存分配失败的问题，则JVM堆太小，需要增加JVM堆大小。
b.如果是偶尔因为为一个大对象分配内存失败，是个独立的事件，则考虑综合的解决方案。
17.Websphere监控和调整堆内存大小：