WAS for z/OSでのTIMEOUTの調査方法 - きどたかのブログ

よくある問題であるため、調査方法はシンプル。

まずはこれを読むのが一番いい。
Webcast Replay: Diagnosing Timeouts in WebSphere Application Server for z/OS
http://www-01.ibm.com/support/docview.wss?uid=swg27007547

少しだけ補足してみる。
IP VERBX CBDATAは古いので、
IP VERBX BBORDATAに読み替えるべき。
CBDATAはAliasだったのだが、V7から削除されている。

Troubleshooting migration
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-zos&topic=tmig_troubleshoot

Note: WebSphere Application Server provides an interactive problem control system (IPCS) verb exit to help you to format information from dumps of WebSphere Application Server processes. This verb exit was named CBDATA, which was an alias of the real module name, in Version 6.x and earlier. In Version 7.0, that alias was removed. In Version 7.0 and later, therefore, you must use the real name of this verb exit, BBORDATA, instead of the alias.

BBOO0327Iメッセージの事が書かれてないので、このメッセージが出てるか意識するべき。
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.messages.doc/com.ibm.ejs.resources.bbooenus.html
ちょっと読みやすくしてみる。

BBOO0327I: {0} REQUEST TIMEOUT: ({1}):({2}):({3}):({4}):({5}):({6}):({7}):({8}):({9}):({10}):({11}):():():({12})
 0 = the type of request
 1 = servant hexadecimal ASID
 2 = request id
 3 = internal information
 4 = servant tcb address
 5 = servant job id or job name
 6 = time request received in controller
 7 = time request queued to wlm
 8 = time request dispatched in servant
 9 = class name
10 = method name
11 = string indicating the origin of the request
?? = future data
?? = future data
12 = request type specific information

IP SUMM FORMATで調べるまでもなくServentのTCBアドレスが判明。
IP VERBX BBORDATA 'ASID(xxxx) TCB(yyyy)'で調べるまでもなく時間に関する情報も判明。
”7 time request queued to wlm”の部分で1つ疑問に思ってるのは、
server_use_wlm_to_queue_work=0でWLM queueを使わない場合でも出るのか否か。
結局IPCSは使う、まだトレースバック見れてないので、
IP VERBX LEDATA 'ASID(xxxx) TCB(yyyy) CEEDUMP'か
IP VERBX LEDATA 'ASID(xxxx) NTHREADS(*)'で見ることになる。

BBORDATAの使い方はここも見たほうがいい。若干だがOUTPUTの内容がある。
IPCS VERBEXIT subcommand to display diagnostic data
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-zos&topic=rtrbverbexitcbdata

IPCSだけでなく、svcdump.jarを使っても確認する。
主にprintThreadsを使ってスタックトレースを見る。
IPCSの結果と違うのを‘java view’と表現してる点に注意。
最近知ったんだが、svcdump.jarはjavacoreも作れるらしい。
Webcast replay: Deep Dive on Java Virtual Machine (JVM) Javacores and Javadumps
http://www-01.ibm.com/support/docview.wss?uid=swg27017906
svcdump.jarは非常に有用で、実際使っているんだが、きっと現場では使われることが無いのだろう。
IPCSだけで全部調べるなんて少し狂ってるから、使えるツールは使えるように準備しとかないといけない。
Zebedeeはsvcdumpの古いコードを書き換えたもので、おそらくDTFJ対応したものを指す。
svcdump.jarにWEB-INFが入っていてサーブレットクラスもあるので、warにして使うことも出来ると思う。web.xmlは入ってないけど。

タイムアウトはEC3 ABENDするが、資料にも載ってるように理由はさまざま。
とりあえずはどのタイムアウトにかかったかは正確に把握する必要はある。
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-mp&topic=rtrb_analyzetimeout

資料中で、SLIPの仕掛け方の説明がある。
タイムアウトしたけどダンプがない場合というのもあるけど、
これはWAS以外のアドレス空間も取りたい場合によく使う。
タイムアウトの原因がDB2やOMVSにあるなんてことはザラなので、そういうのに向いてる。

最初の資料でワーカースレッドを確認しているのは意味がある。
CUSTOMEのことが書いてないけど、それも当然見る。
これは主にコネクション待ちなどの場合における設定ミスを疑う。
データソースやコネクションファクトリーの、コネクションプールやセッションプール。
MDBならリスナーポートやアクティベーションスペックの設定も関係する。
この種の確認をする際、サーバーの構成情報の提示を求められるだろう。
アプリケーションのejb-jar.xmlやejb-jar-bnd.xmlとかも。
しかし、コネクションやセッションの必要数というものは、
アプリケーション依存するため、これらの資料から正解を出すことは出来ない。
これらの資料から弾き出せるのは、明らかに足りてない場合のみである。
だから手放しでサポートに任せられる代物ではない。
もしもコネクションリーク系の疑いがあるなら、トレースを取る流れになるだろう。

EC3 ABENDしないが、レスポンスが遅いというのには、別のアプローチがある。
（Transaction TimeoutのROLLBACK ONLYなんかも、欲しい情報は取れてないだろう）
そういう場合はDPMを使ってダンプを取る。たぶんjavacoreを取るのからはじめることになるだろう。
Monitoring dispatch requests
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-zos&topic=tprf_monitor_dispatch_requests
WebSphere Application Server for z/OS V7 - Dispatch Timeout Improvements
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101374
V7で難点なのは、レスポンスタイムの早いのと遅いのが同一サーバーに同居してる場合かな。とりたくないダンプを取ってしまうことになる。
V8.0以降であれば、wlm classification fileで細かくDPMを設定できるのでそういうのが緩和できる。

JDKの観点では、dump eventで何かやれないかというのは考えられるのだが、
dump agentの設定は再起動が必要になるので本番環境にはまず無理。