WebSphere Application Hang

时间:2016-02-23 21:16:38

标签: jvm websphere zos ibm-was ibm-jvm

如果在z / OS上挂起了WebSphere Application,应该采取哪些步骤来查找原因?

到目前为止,我采用了堆转储,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)

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

2 个答案:

答案 0 :(得分:2)

z / OS的最佳功能之一是诊断功能 - 你永远不必猜测......它几乎总能找到完全正在发生的事情。

就个人而言,我从系统转储和IPCS开始。当然,这是一种非常罕见的技能,所以如果这不是你的事情,那么第一步可能就是找一个具有良好转储技能的人。如果您完全陷入困境,那么会有一个很好的介绍here

首先确保您的转储具有您认为的转储...系统转储的大部分最终包括错误的地址空间或错误的数据区域,这些都是无用的。如果您遇到这种情况,那么现在应该准确设计所需的转储选项,以便在下次出现问题时捕获所需的内容。

通过使用WebSphere IPCS转储格式化程序,您可以很好地了解WebSphere内部的内容 - 概述为here

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

很大程度上,找到一个等待的原因是关于通过TCB / RB结构找到PSW并在等待时注册...这告诉你模块正在等待,而且很可能你可以弄清楚这里发生了什么。

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

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

不要忘记你总是可以联系IBM支持 - 你在像WebSphere这样的软件上花了很多钱,所以伸出手去让他们解释一下发生了什么肯定是更好的想法。

祝你好运!

答案 1 :(得分:1)

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

不幸的是,仍然无法解释为什么它会被困在第一位。