2

WebSphere アプリケーションが z/OS でハングした場合、原因を見つけるためにどのような手順を実行する必要がありますか?

ここまでで、ヒープ ダンプ、Java コア、およびシステム ダンプを取得しました。

どのスレッドもデッドロックしておらず、メモリの問題もなく、スレッドが豊富にあるようにも見えません。(ごく普通の 50 までです。)

アプリケーション全体にアクセスできません。つまり、Web ページに接続しようとすると、ハングしてタイムアウトになります。

これを引き起こすことによって何ができますか？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 の最も優れた機能の 1 つは、診断機能です。推測する必要はありません...何が起こっているのかを正確に知ることは、ほぼ常に可能です。

個人的には、システム ダンプと IPCS から始めたいと思います。もちろん、これは最近では非常にまれなスキルです。そのため、これが苦手な場合は、最初のステップとして、優れたダンプ リーディング スキルを持つ人を見つけることをお勧めします。完全に立ち往生している場合は、ここに良い紹介があります。

まず、ダンプにあると思われるものが含まれていることを確認することから始めます...システム ダンプのかなりの割合が、間違ったアドレス空間または間違ったデータ領域を含むことになり、これらはほとんど役に立ちません。このような状況にある場合は、必要なダンプ オプションを正確に設計して、次に問題が発生したときに必要なものを取得できるようにします。

WebSphere IPCS ダンプ・フォーマッターを使用すると、WebSphere の内部で何が起こっているかについての概要を把握できます。概要はここにあります。

WebSphere アドレス空間には多くのスレッドがあり、これらには z/OS TCB (タスク制御ブロック) があります。最後の TCB (IPCS では、SUMM FORMAT コマンドまたは同等のもの) をすべて調べて、それが実行中 (ループしている可能性がある) か待機中かを理解します。私の賭けは、スレッドが何かを待っているということです...ロック、外部信号、DB2への呼び出し、いくつかのベンダーソフトウェアなど-良い目標は、すべてのスレッドのリストを作成し、それぞれが正確に何をするかです一人は待っています。

ほとんどの場合、待機の理由を見つけるには、待機時に TCB/RB 構造を調べて PSW とレジスタを見つける必要があります。 .

ダンプを取得する前にシステムが長時間ハングしていなかった場合は、システム トレース テーブルを確認することもできます。アドレス空間が何をしてきたかの履歴が表示されますが、長期間経過している場合はそこにデータがあまりない可能性があります。

また、WebSphere は巨大な UNIX サービス アプリケーションであるため、ダンプに OMVSDATA がある場合は忘れずに確認してください。

いつでも IBM サポートに連絡できることを忘れないでください。WebSphere のようなソフトウェアには多額のお金を費やしているため、連絡を取り、何が起こっているのかを説明してもらうことは、確かに優れたアイデアの 1 つです。

幸運を！

于 2016-07-26T17:07:50.107 に答える