WebLogic诊断篇之常规服务器挂起故障
问题描述
在出现以下情况时怀疑服务器挂起:
· 服务器不响应新的请求。
· 请求超时。
· 请求处理的时间越来越长(其最终结果可能是挂起)。
通常,服务器挂起不会表现为服务器崩溃,但服务器挂起之后可能会崩溃。
故障排除
请注意,并非下面所有任务都需要完成。有些问题仅通过执行几项任务就可以解决。
为什么发生此问题?
服务器挂起有多种原因。一般而言,服务器挂起是因为缺少某种资源。缺少资源会阻止服务器响应服务请求。例如,由于故障(死锁)或者大量请求的缘故,可能没有任何可用的执行线程来完成工作,所有执行线程都被占用或忙于处理以前的请求。
服务器挂起的可能原因
基本步骤
(1)从命令行对服务器执行ping 命令
当服务器挂起时,首先使用 java weblogic.Admin t3://server:port PING 来 ping 该服务器。如果服务器能够响应此 ping,则可能是应用程序正在挂起而不是服务器自身。
(2)检查服务器是否正在执行垃圾回收
确保服务器确实正在挂起,而不是在做垃圾回收。若要验证挂起,加上-verbose:gc 参数,并且将 stdout 和 stderr 重定向到一个文件中,重新启动服务器。当服务器停止响应时,可以判断它是正在收集无用信息还是确实挂起。
(3)查看执行现场运行状态
查看执行线程的运行情况,如果一个空闲线程都没有的话,那么狠可能会导致服务器挂起,WebLogic Server 使用“Default”线程队列响应客户端服务请求,可以查看default队列里是否有空闲的执行线程。登录控制台,然后依次执行DomainName->Servers->ServerName->Monitoring->General->Monitor All Active Queues->weblogic.kernel.Default 命令,里面的Current Request 列会显示线程是否正在工作。
已知的 WebLogic 问题
JDBC 产生死锁问题的可能性存在。检查在 weblogic.log 开头找到的服务器的版本和 Service Pack 级别。然后对已经应用于服务器类路径的所有临时修补程序检查以上版本和 Service Pack 行。修补程序将指明已经解决了什么问题。
收集 Thread Dump
进行 Thread Dump 的方法取决于安装挂起服务器实例的操作系统。Thread Dump 提供关于每个线程在特定时刻正在执行什么操作的信息。检查 Thread Dump,了解每个线程在服务器挂起时正在执行的操作。这有助于分析下一个探查阶段。例如,如果 JSP 编译中涉及许多线程,参考服务器挂起的可能原因一节可了解进一步的诊断和测试操作。
初始探查结果分析
下面是其中一个线程在 Thread Dump 中的形式示例。Execute Thread 14 正在等待任务。该线程调用的最后方法是 Object.wait()。
确定“Default”ExecuteThread 队列是否超载。利用控制台确定“Default”队列中的所有 ExecuteThreads 是否空闲。如果没有一个空闲,则应用程序可能需要一个更大的 ExecuteThread 数来配置。可以通过控制台更改该值,并将其保存在 config.xml 文件中。
如果执行队列有空闲线程,则可能没有分配足够的 Socket Reader 线程。缺省情况下,WebLogic Server 实例在启动时创建三个 Socket Reader 线程。如果群集系统在高峰期使用的 Socket Reader 线程超过三个,则增加 Socket Reader 线程的数量。
通常,Socket Reader 线程的数量应当较小。但是,如果 Weblogic Serve 充当正在挂起的服务器实例的客户端,则应当为每个 Weblogic Serve 配置一个线程。
如果使用 JDBC 连接池,确保池中已经配置的 JDBC 连接数量与同时请求(即执行线程)的数量相等。
故障排除检查清单
(1)确认服务器是否已挂起,并确定服务器状态:崩溃、最终恢复正常,还是这两种情况均未发生。
(2)收集初始探查数据
a) 如果没有数据,可设置参数以供下次发生挂起时使用
b) 检查线程活动并进行若干次Thread dump
(3)查找服务器挂起的根本原因
a) 可用的执行线程数和Socket Reader线程数是否充足?是否有监听线程?
b) GC是否正在运行?
c) 对Thread dump进行分析,查找可能原因,参考特定模式
(4)根据需要更改配置,增大导致服务器挂起的限值
(5)根据需要探查具体的故障成因。
(6)继续监视,看是否还会发生故障