読者です 読者をやめる 読者になる 読者になる

きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

STOPコマンドでWASが停止しない時の正しい対処

開発環境では結構起ってると思う事象で、
これが本番で起きたらどう対処するべきかを考えていた。


多くの人が取る行動は以下のものだと思う。

  • ダンプを取る
  • CANCELコマンド
  • (それでも駄目なら)FORCEコマンド


惜しい、これでは80点。


ここから少しだけ私の提案ベースの内容があります。
まず一番初めにやることは、CRがSTOPコマンドを受け取ったか確認すること。
BBOO0133I: WEBSPHERE FOR Z/OS STOP COMMAND ISSUED FOR SERVER {0}.


SRでアプリケーションが停止し始めているかを確認すること。
WSVR0217I: Stopping application: {0}
もし、SRがアプリケーションを停止し始めてないのであれば、
CRからSRへの通信に失敗してるという予想もできる。


リクエストが残ってないかを確認すること。
F ,DISPLAY,WORK,ALL
F ,DISPLAY,THREADS,ALL


F ,DISPLAY,THREADSは、Information Centerにも一応載っています。
こっちには載ってませんが、
Network Deployment (z/OS), Version 7.0 > Reference > Command-line utilities > Modify command
こっちには載ってます。
Network Deployment (z/OS), Version 7.0 > Reference > Command-line utilities > Display command with examples
このような神隠しにあってるコマンドです。

詳しく知りたい人はこれも読むといい。
IBM Techdocs White Paper: WebSphere Application Server for z/OS V7 - Dispatch Timeout Improvements
SRがDISPATCHしたリクエストだけ出るようで、WLM Queueに入ってるだけのは出ないらしいです。


さて、もしもF ,DISPLAY,THREADS,ALLでリクエストが残ってるのが分かった場合、もう少し詳細に出してみましょう。
F ,DISPLAY,THREADS,REQUEST=xxxxxxxx,DETAILS
xxxxxxxxの箇所には、F ,DISPLAY,THREADS,ALLの出力結果から選びます。
これでリカバリー出来るわけではないですが、
何か分からないまま止めるよりもその後の解析が楽になるはずです。
TCBアドレスが表示されたり、時間が分かったりしますから。


Whitepaperでは、AGEやTIMEOUTでフィルターする方法が記載されています。
確かにこれらには意味があるかもしれない。
control_region_timeout_delayが設定されていたりとか、
control_region_timeout_save_last_servantが設定されていたりとか、
各種timeout_output_recoveryがSESSIONと設定されていたりとか、いくつか思い当たる状況がある。


ここから先はMustGatherをもとにした話。
IBM MustGather: A hang occurs when attempting to stop WebSphere Application Server for z/OS - United States


私の書いた内容は、a)のパターン(アプリの、ある種の運用の問題)をカバーしようとしているわけです。
MustGatherの内容はb)とc)を扱ってます。
説明にしたがってトレースとダンプを取りましょう。
AppServerの場合、ORBに限定して取ってますが、全部取っても構わないでしょう。
どうせ止めるんだから、パフォーマンスは考えなくていいし。
トレース仕掛けたらSTOPコマンドを試す。
MustGatherでは次のメッセージを確認するようにいってます。
"BBOO0133I WEBSPHERE FOR Z/OS STOP COMMAND ISSUED FOR SERVER..."
しかし、STOPコマンドがすでに受け付けられていたら、こっちが出るはずです。
BBOO0150E: COMMAND IGNORED, STOP COMMAND ALREADY ISSUED FOR SERVER {0}
ふむ、サーバー停止のたびに出るというのを時間をかけて対処するのであれば、
あのような説明になるんでしょうね。


私がここで思い描いてるのは、
サーバー停止時の問題はMustGatherが用意されてるほど比較的起こるので、
あらかじめプランを用意しておきましょうということです。
次の計画停止の時はトレース取ってSTOPしましょうではない。
ダンプを取る以外に5分でいいから時間を割きましょう。
30分とか1時間かかるようなことは考えてない、状況によって出来ないだろうから。
5分なら捻出出来ないだろうか、許容されないだろうか。


1度目のSTOPコマンドにしても
F ,PAUSELISTENERS して
F ,DISPLAY,WORK,ALL や
F ,DISPLAY,THREADS,ALL をした後でも良いと思う。
それがあるだけで、解析の時に考えることが減る。


1度目のSTOPコマンドで、CRはSRからのレスポンス待ちって状況が多いので、
その状況でトレース取ってもどれだけの内容が出るかは分からないという疑念はあるのだけれど、
リクエストが来てるかも知れないのにSTOPとか普通ありえないでしょう。


最後に、PAUSELISTENERSについて知りたい人はこれを読むといいよ。
IBM Techdocs White Paper: WebSphere z/OS V6.1 - Hidden Gems and Little Known Features