问题描述
在出现以下情况时怀疑服务器挂起：

• 服务器不响应新的请求。
• 请求超时。
• 请求处理的时间越来越长（其最终结果可能是挂起）。
• 通常，服务器挂起不会表现为服务器崩溃，但服务器挂起之后可能会崩溃。

快速链接：

• 为什么发生此问题？
• 服务器挂起的可能原因
• 基本步骤
• 已知的 WebLogic Server 问题
• 收集 Thread Dump
• Thread Dump 分析

为什么发生此问题？
服务器挂起有多种原因（请参考服务器挂起的可能原因一节）。一般而言，服务器挂起是因为缺少某种资源。缺少资源会阻止服务器响应服务请求。例如，由于故障（死锁）或者大量请求的缘故，可能没有任何可用的执行线程来完成工作，所有执行线程都被占用或忙于处理以前的请求。

返回页首

服务器挂起的可能原因

返回页首

基本步骤
当服务器挂起时，首先使用 java weblogic.Admin t3://server:port PING 来 ping 该服务器。如果服务器能够响应此 ping，则可能是应用程序正在挂起而不是服务器自身。

确保服务器确实正在挂起，而不是在做垃圾回收。若要验证挂起，启用 -verbosegc 重新启动服务器，然后将 stdout 和 stderr 重定向到一个文件中。当服务器停止响应时，可以判断它是正在收集无用信息还是确实挂起。

WebLogic Server 使用“Default”线程队列响应客户端服务请求。这些是在发生服务器挂起时应当检查的线程。下面是其中一个线程在 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 连接数量与同时请求（即执行线程）的数量相等。

返回页首

已知的 WebLogic 问题
JDBC 产生死锁问题的可能性存在。检查在 weblogic.log 开头找到的服务器的版本和 Service Pack 级别。然后对已经应用于服务器类路径的所有临时修补程序检查以上版本和 Service Pack 行。修补程序将指明已经解决了什么问题。

返回页首

收集 Thread Dump
进行 Thread Dump 的方法取决于安装挂起服务器实例的操作系统。有关在不同的操作系统上进行 Thread Dump 的信息，可以在以下网址中找到：http://e-docs.bea.com/wls/docs81/cluster/trouble.html#gc。

Unix 系统（Solaris、HP、AIX）
使用 kill .3 <weblogic process id> 创建诊断问题所需的 Thread Dump。确保在每个服务器上执行几次，每次间隔大约 5 到 10 秒，以帮助诊断死锁问题。为达到诊断目的，用 nohup 启动服务启进程（请参考解决方案 S-12292 和 S-15924）。

Windows、XP、NT
每个服务器需要 <Ctrl>-<Break> 来创建诊断问题所需的 Thread Dump。确保在每个服务器上执行几次，每次间隔大约 5 到 10 秒，以帮助诊断死锁问题。在 NT 上，在命令 shell 中输入 CTRL-Break。

Linux
Linux 操作系统查看线程的方式不同于其它操作系统。该操作系统将每个线程视为一个进程。若要在 Linux 上进行 Thread Dump，查找通过其启动所有其它进程的进程 ID。使用命令：

• 若要获得根 PID，使用：

  ps -efHl | grep 'java' **. **

使用一个作为字符串的 grep 参数（可在与服务器启动命令匹配的进程堆栈中找到该字符串）。如果 ps 命令还没有管道传送到另一个例程，则报告的第一个 PID 将是根进程。

• 使用 weblogic.Admin 命令 THREAD_DUMP

进行 Thread Dump 的另一种方法是使用 THREAD_DUMP admin 命令。此方法与正在运行服务器实例的操作系统无关。

java weblogic.Admin -url ManagedHost:8001 -username weblogic -password weblogic THREAD_DUMP

备注： 如果无法 ping 服务器实例，则不可以使用该命令。

如果正在使用的 JVM 是 Sun 开发的，则 Thread Dump 转为 stdout（标准输出文件）。Sun 已经增强了 JVM 1.3.1 和 1.4 之间的 Thread Dump 格式。若要获得 Sun JVM 1.4 的 Thread Dump 格式，将下列选项添加到启动 1.3.1 JVM 的 java 命令行中：

-XX:+JavaMonitorsInStackTrace

返回页首

Thread Dump 分析
分析服务器挂起的最有用的工具是一系列 Thread Dump。Thread Dump 提供关于每个线程在特定时刻正在执行什么操作的信息。一系列 Thread Dump（一般每隔 5 到 10 秒进行三个或更多 Thread Dump）可以帮助分析每个线程从一个 Thread Dump 到另一个 Thread Dump 过程中的状态变化或所缺少的变化。挂起服务器 Thread Dump 一般显示线程状态从第一个 Thread Dump 到最后一个 Thread Dump 中变化很小。

在 Thread Dump 中查看的内容
所有请求都通过 ListenThread 进入 WebLogic Server。如果 ListenThread 丢失，就无法接收任何工作，因此也无法完成任何工作。确认在 Thread Dump 中存在 ListenThread。ListenThread 应当在 socketAccept 方法中。下面示例说明监听线程 (Listen Thread) 的形式。

"ListenThread.Default" prio=10 tid=0x00037888 nid=93 lwp_id=6888343 runnable [0x 1a81b000..0x1a81b530]at java.net.PlainSocketImpl.socketAccept(Native Method)
at
java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)
- locked <0x26d9d490> (a java.net.PlainSocketImpl)
at
java.net.ServerSocket.implAccept(ServerSocket.java:439)
at
java.net.ServerSocket.accept(ServerSocket.java:410)
at
weblogic.socket.WeblogicServerSocket.accept(WeblogicServerSocket.java:24)
at
weblogic.t3.srvr.ListenThread.accept(ListenThread.java:713)
at
weblogic.t3.srvr.ListenThread.run(ListenThread.java:290)

"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00036128 nid=75 lwp_id=6888070 waiting for monitor entry [0x1b12f000..0x1b12f530]
at
weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:92)
- waiting to lock <0x25c01198> (a java.lang.String)
at
weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:32)
at
weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)
at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)

"ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00035fc8 nid=74 lwp_id=6888067 runnable [0x1b1b0000..0x1b1b0530]at weblogic.socket.PosixSocketMuxer.poll(Native Method)
at
weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:99)
 - locked <0x25c01198> (a java.lang.String)
at
weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:32)
at
weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)
at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)

"ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00035e68 nid=73 lwp_id=6888066 waiting for monitor entry [0x1b231000..0x1b231530]
at
weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:92)
- waiting to lock <0x25c01198> (a java.lang.String)
at
weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:32)
at
weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)
at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)

ThreadPoolPercentSocketReaders 属性设定要用于从 java Socket 中读取消息的执行线程的最大百分比。此属性的最佳值是针对应用程序设定的。缺省值为 33，有效范围是 1 到 99。

分配执行线程充当 Socket Reader 线程可提高服务器接受客户端请求的速度和能力。必须平衡专门用于从 Socket 读取消息的执行线程和那些在服务器中执行实际运行任务的线程的数量。

后续步骤
后续步骤要求进一步分析 Thread Dump。检查 Thread Dump，了解每个线程在服务器挂起时正在执行的操作。这有助于分析下一个探查阶段。例如，如果 JSP 编译中涉及许多线程，参考服务器挂起的可能原因一节可了解进一步的诊断和测试操作。

返回页首

文章出处：http://www.bea.com.cn/support_pattern/Generic_Server_Hang_Pattern.html