故障诊断学习工具：在实践中学习WebSphere应用服务器故障诊断.doc

故障诊断学习工具：在实践中学习WebSphere应用服务器故障诊断

引言
WebSphere 应用服务的故障诊断一直是客户最为关心的问题之一。为了对 WebSphere 应用 服务器进行快速的问题诊断， IBM 提供了广泛的支持，包括帮助客户进行快速的数据采集，指 导客户进行数据分析以及提供大量的参考手册和技术文档等，这些努力大大减轻了问题诊断的 工作量。然而，问题的解决最终还是要依赖于用户对具体问题的分析。这就像是医生给病人看 病，任何先进的医疗器械和理论知识都代替不了医生的诊断，为了给病人治病，医生不仅要有 扎实的理论基础，还要有丰富的实践经验，对 WebSphere 应用服务器进行问题诊断也是一样。 那么怎样才能获得故障诊断相关的经验呢？ 在实践中学习当然是我们获得经验的最佳途径，但 仅仅依靠在工作中解决实际问题来获得经验将是一个漫长的过程，并且通常都需要付出一定的 代价。与之相比，另一种主动的方式 – 实验 – 要划算的多，通过实验的方式获得经验不仅 可以帮助我们在问题发生时进行快速的诊断，而且还有可能因为这些已有的经验避免一些问题 的发生。本文将介绍一种进行问题诊断的实验工具 – Problem Diagnostics Lab Toolkit （ 它可以帮我们快速重现问题，并且为问题 的定位和诊断提供指导。
什么是 Problem Diagnostics Lab Toolkit ？
Problem Diagnostics Lab Toolkit (PDLT) 是一个安装在 WebSphere Application Server 上的企业应用程序，与普通的应用程序相比，它的特点是可以动态的修改需要运行 Java 代码 ，这些 Java 代码是通过应用程序写到 jsp 中的，所以当用户在浏览器中修改相应的代码以后 ，不需要重起应用程序，就能立即执行新的代码。包含 Java 代码的 jsp 可以通过 "动作面板 " 中的按钮来调用的 , 这样无论是修改还是运行 Java 代码都非常的方便。监控模块可以帮助 我们察看系统当前的状态，包括线程状态、内存和 CPU 使用情况，以及不同请求的响应时间等 。 PDLT 还包含一个内置的压力引擎，当我们需要重现一些在压力条件下才能重现的问题时， 可以设置模拟的客户端的个数、每个客户端的请求数以及两次请求之间的时间间隔。下图展示 了 PDLT 的主要功能模块：
图 1. PDLT 的功能模块

管理模块： 主要负责实验案例的管理和维护。
代码编辑器： 动态修改 Java 代码，修改后的 Java 代码可以立即被执行，而不需要重新 部署应用程序。
监视模块： 监视应用程序的运行状态，比如内存、CPU、线程和平均响应时间等。
压力引擎： 模拟多客户端对 Java 代码（JSP) 进行访问。
案例库： 存放的案例。
Problem Diagnostics Lab Toolkit 的安装
PDLT 是一个的企业应用程序，用户需要将其部署在 WebSphere 的单 Server 环境中，部署 过程中只需要接受默认的配置即可，不需要配置额外的资源和环境变量。
具体安装步骤如下：
1) 从 下载 PDLT。
2) 启动 WAS，并打开 admin console 。
3) 选择“应用程序”->“安装新的应用程序”。
4) 选择压缩包中的 ear 文件。
5) 全部使用默认选项安装该 ear 。
安装完成后，用户可以通过浏览器访问 http://hostname:port/LabToolkit，其界面如下图 所示
图 2. PDLT 的界面

问题 (Problem): 是对实验场景的分类，每一类问题可以通过多个场景来进行重现。
场景 (Scenario): 用于重现问题的实验场景，每一个场景包含一个向导和一个动作面板。
向导（Wizard): 指导用户完成场景中的步骤。
动作面板 (Action Pane): 包括一系列动作按钮，每个动作按钮对应后台的一个 jsp 文件 ，用户可以执行或者修改这个 jsp 文件中的代码。
监视器 (Monitor): 用户监控系统的状态。
消息面板 (Message Console): 用于显示运行过程中的日志消息。
Problem Diagnostics Lab Toolkit 的使用
了解试验场景
每一个试验场景代表一种可能发生问题的情况，用户首先选择一个问题类别，然后在该类别 中选择一个试验场景，这里我们以死锁问题为例，选择 “ThreadHang" --> "DeadLock"，
这时我们可以看到这个实验场景的向导（图 3）和动作面板（右侧），向导主要分为四个步 骤 :
简介 (Instruction): 主要介绍该场景所要重现的问题。
问题重现 (Reproduction)：介绍重现该场景的步骤和注意事项。
分析问题 (Investigation): 指导用户进行问题诊断
总结 (Summary): 问题总结。
通过鼠标右键弹出的上下文菜单，用户可以增加或者删除向导的步骤或者对向导中的内容进 行修改。
图 3. 向导部分

图 4. 动作面板

查看代码
"Dead Lock" 的动作面板中有两个动作按钮，"DeadLock Jsp" 按钮和 "Correct Jsp"。
用鼠标右键单击 "DeadLock Jsp" 按钮，在快捷菜单中选择 "Edit Action Button" ，在弹 出的 Java 编辑器中我们可以查看或者编辑这个按钮所执行的 Java 代码，其代码如下：
清单 1.“DeadLock Jsp” 按钮执行的 Java 代码
synchronized　(lock1)　{　//　lock1　is　defined　in　the　"Methods　and　 Static　Variables"　tab
　　　 Thread.sleep(5000);
　　　 ThreadMonitor.registerThreadStatus("blocked");
　　　 //It　will　be　blocked　here　if　the　thread　can　not　get　the　 lock2
　　　 synchronized　(lock2)　{
　 ThreadMonitor.registerThreadStatus("running");
　 //It　will　continue　to　run　if　the　thread　can　get　the　lock2
　 }
　 }
　　 synchronized　(lock2)　{　//　lock2　is　defined　in　the　"Methods　and　 Static　Variables"　tab
　　　 Thread.sleep(5000);
　　　 ThreadMonitor.registerThreadStatus("blocked");
　　　　 //It　will　be　blocked　here　if　the　thread　can　not　get　the　 lock1
　　　 synchronized　(lock1)　{
　　 ThreadMonitor.registerThreadStatus("running");
　　 //It　will　continue　to　run　if　the　thread　can　get　the　lock1
　 }
　 }
图 5. 代码编辑器

这段代码主要完成如下操作：
获取一个全局锁 locker1
（Sleep(5000))
获取一个全局锁 locker2
释放全局锁 locker2
释放全局锁 locker1
获取一个全局锁 locker2
（Sleep(5000))
获取一个全局锁 locker1
释放全局锁 locker1
释放全局锁 locker2
这段代码在单线程运行时可以很顺利的执行，但在多线程并发条件下却很容易发生死锁：当 两个不同的线程分别执行到第 2 步和第 6 步之前时 , 其中的一个线程已经占用了 locker1, 它需要等待 locker2, 而另一个线程则刚好相反。 因此如果我们模拟多用户并发执行这段代码 ，就能够重现死锁问题。
模拟多用户并发
PDLT 内置了压力引擎，可以方便的模拟多用户并发调用的场景，如下图所示，展开动作面 板下方的 Advanced Settings"面板，可以设置模拟客户端的个数，发送请求总数以及请求之间 的间隔时间。这里我们将用户数设置为 2。返回动作面板并单击"DeadLock Jsp" 按钮，压力引 擎会同时发送 2 个请求来调用"DeadLock Jsp" 按钮所对应 jsp，从而运行上面我们所编辑的 代码。
图 6. 设置压力引擎

监控线程运行情况
展开“Monitors”面板，可以看到 3 个 tab 页， 分别用来监控线程信息、内存和 cpu 使 用情况以及请求的平均响应时间。 这里我们主要关心线程的运行情况，从线程信息页我们可以 看到刚刚运行的两个新的线程都处于“block”状态，并且这种状态会一直持续下去。 这就是 死锁，它不但导致发生死锁的两个线程无法正常结束，这两个线程所占用的资源还会影响到更 多的线程， 当线程总数超过 Web Container 线程池的最大线程数时，则所有的请求都会被拒 绝。
图 7. 监控运行情况

察看正确代码
用鼠标右键单击 "Correct Jsp" 按钮，在快捷菜单中选择 "Edit Action Button"，在弹出 的 Java 编辑器中我们可以查看或者编辑这个按钮所执行的 Java 代码，其代码如下：
清单 2.“Correct Jsp” 按钮执行的 Java 代码
synchronized　(lock1)　{　//　lock1　is　defined　in　the　"Methods　and　 Static　Variables"　tab
　　　 Thread.sleep(5000);
　　　 ThreadMonitor.registerThreadStatus("blocked");
　　　 synchronized　(lock2)　{
　 ThreadMonitor.registerThreadStatus("running");
　 }
　 }
synchronized　(lock1)　{　//　lock2　is　defined　in　the　"Methods　and　Static 　Variables"　tab
　　　 Thread.sleep(5000);
　　　 ThreadMonitor.registerThreadStatus("blocked");
　　　 synchronized　(lock2)　{
　　 ThreadMonitor.registerThreadStatus("running");
　 }
　 }
这段代码主要完成如下操作：
获取一个全局锁 locker1
（Sleep(5000))
获取一个全局锁 locker2
释放全局锁 locker2
释放全局锁 locker1
获取一个全局锁 locker1
（Sleep(5000))
获取一个全局锁 locker2
释放全局锁 locker2
释放全局锁 locker1
与 “DeadLock Jsp” 相比，我们在这段代码中仅仅调整了一下 locker1 和 locker2 的嵌 套顺序，但当我们用两个（或者更多）客户端同时发出请求时，所有线程都能够正常结束。
因此，在多线程环境下，一定要保证锁的嵌套顺序是一致的，这样才能避免死锁的发生。
结束语
除了死锁问题之外，PDLT 还包含很多其他常见的典型问题，比如 Java 内存溢出、本地内 存溢出、CPU 使用率过高、连接泄漏等。 对于这些常见的错误，用户最好在问题发生之前就对 它进行了解，了解这些问题发生时系统的症状，以及如何诊断和解决这类问题。这样当真正的 问题到来的时候才能迅速做出判断，从而减少由于系统中断而带来的损失。