2

如果一个 WebSphere 应用程序在 z/OS 上挂起，应该采取哪些步骤来查找原因？

到目前为止，我学习了堆转储、Java 核心和系统转储。

没有一个线程死锁，没有内存问题，而且似乎没有大量线程。（只有~50，这是相当正常的。）

整个应用程序不可访问。我的意思是，任何连接到它的网页的尝试都会挂起并超时。

造成这种情况的原因是什么？我正在考虑一个高 CPU 事件，但不确定如何追溯检查。

我收到与此类似的错误消息 30 次。

BBOO0221W: WSVR0605W: Thread "WebSphere WLM Dispatch Thread t=008b74f8" (00000075) has been active for 720962 milliseconds and may be hung.  There is/are 30 thread(s) in total in the server that may be hung.
at sun.reflect.GeneratedMethodAccessor617.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at com.sun.faces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:126)
    at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:72)
    at javax.faces.component.UICommand.broadcast(UICommand.java:312)
    at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:267)
    at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:381)
    at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:75)
    at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
    at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97)
    at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:97)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
(truncated)

“挂起”的线程本身似乎没有任何真正的模式，它们只是正常的活动，不应该挂起。

4

2 回答 2

3

z/OS 的最佳特性之一是诊断功能——您永远不必猜测......几乎总是可以准确地找出正在发生的事情。

就个人而言，我将从您的系统转储和 IPCS 开始。当然，现在这是一项非常罕见的技能，所以如果这不是你的事，第一步可能是找一个有良好的垃圾阅读技能的人。如果你完全被卡住了，这里有一个很好的介绍。

首先确保您的转储具有您认为的内容......很大一部分系统转储最终包括错误的地址空间或错误的数据区域，而这些几乎没有用。如果您处于这种情况，是时候准确地设计您想要的转储选项，以便在下次出现问题时捕获您需要的内容。

通过使用 WebSphere IPCS 转储格式化程序，您将对 WebSphere 内部发生的事情有一个很好的概述 - 概述在这里。

在 WebSphere 地址空间中，将有许多线程，这些线程将具有 z/OS TCB（任务控制块）。遍历每一个最后的 TCB（在 IPCS 中，SUMM FORMAT 命令或等效命令）并了解它是在运行（可能循环）还是在等待。我敢打赌，线程正在等待某些东西……锁、外部信号、对 DB2 的调用、某些供应商软件等 - 一个好的目标是列出所有线程以及每个线程的确切内容一个正在等待。

很大程度上，寻找等待原因是通过 TCB/RB 结构来找到等待时的 PSW 和寄存器……这告诉你正在等待的模块，你很可能可以从这里弄清楚发生了什么.

如果在您进行转储之前系统没有挂起很长时间，您还可以检查系统跟踪表。它将为您提供地址空间一直在做什么的历史记录，尽管如果时间很长，那里可能没有太多数据。

此外，由于 WebSphere 是一个巨大的 UNIX 服务应用程序，如果您的转储中有 OMVSDATA，请不要忘记查看它。

不要忘记，您始终可以寻求 IBM 支持——您在 WebSphere 之类的软件上花费了大量资金，因此请他们解释正在发生的事情肯定是更好的想法之一。

祝你好运！

于 2016-07-26T17:07:50.107 回答
1

应用程序没有响应，因为您所有的调度线程（显然是 30 个）都被占用了。新请求只是在 WLM 队列中堆积起来，直到触发一些超时。WAS z/OS 中的调度超时最终应该异常终止服务区域，并且 WLM 将启动一个新的（除非您关闭了超时）。这里有一篇关于 z/OS 上的 WAS 超时管理的好文章： http ://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102510 。

不幸的是，这仍然不能解释为什么它首先被卡住了。

于 2016-02-24T14:35:10.077 回答