[z/OS]

超时条件:分析诊断数据

以下准则提供在 SVC 转储中查找诊断数据的指示信息,这些数据可帮助您确定发生了何种超时情况。

应通过查找有 EC3 异常结束的任务开始:
  1. 通过输入以下命令,格式化超时的服务方的 TCB 总结:
    ip summ format asid(x' address ')

    其中 address 是服务方的地址空间标识。

    查找有 EC3 完成代码的 TCB。忽略“主”线程上的任何 EC3 完成代码,该线程是总结格式中列出的第 4 个 TCB(3 个 MVS™ TCB 后的第 1 个)。WebSphere® 主线程是在 BBO_BOA::impl_is_ready 中等待的线程。在此线程上从未分派应用程序请求,因此没有要超时的。在超时处理期间,也会用 EC3 异常结束服务器区域的主线程,作为降低地址空间的机制。这就是为什么 EC3 完成代码可能出现在主线程中。这从不是超时的原因,而仅是超时处理的结果。

  2. 如果在 TCB 总结中没有 EC3 完成代码,请查看 systrace。 将 systrace 格式化为格林威治时间,因为要与之比较的其他时间戳记为格林威治时间。要采用格林威治时间格式,输入以下命令:
    ip systrace all time(gmt)

    可能您在 systrace 中也见不到 EC3 异常结束,因为 systrace 只能覆盖一小段时间。

  3. 您还可尝试查看 ip verbx mtrace 或 syslog,看 EC3 异常结束何时发生。您将需要该时间来确定请求的“结束”时间,它是达到超时值的格林威治时间。
可通过检查与 EC3 异常结束关联的原因码,确定哪些超时值有效。
表 1. 原因码和说明. 可通过检查与 EC3 异常结束关联的原因码,确定哪些超时值有效。
原因码 说明
04130002 控制器为此服务方区域发出一个 ABTERM,这是因为发生了事务超时。分派下的代码可能已进入紧密循环。
04130003 控制器为此服务方区域发出一个 ABTERM,因为它尝试将控制器请求传送到服务方区域时已挂起。目标请求已超时,但服务方当前正在复制请求。控制器通过发出 ABTERM,在采取操作前按常规时间间隔检查服务方的进展。
04130004 控制器为此服务方区域发出一个 ABTERM,因为发生了 WLM 队列超时。分派下的代码可能已进入紧密循环。
04130005 控制器为此服务方区域发出一个 ABTERM,这是因为发生了事务超时。事务已超时,但未找到与事务关联的当前请求。将终止与事务关联的服务方。
04130006 控制器线程在处理请求时遇到问题。请求已被排队到 WLM,并与服务方区域关联。需要终止关联的服务方区域以完成请求的清除。
04130007 控制器为此服务方区域发出一个 ABTERM,因为发生了 HTTP OUTPUT 超时。分派下的代码可能已进入紧密循环。
您可尝试查找方法名称以确定它是
 httpRequest
,
 httpsRequest
 DispatchbyURI
还是某个其他方法。如果请求并不是明确地通过 HTTP 或 HTTPS 传输处理程序的请求,那么不考虑
 protocol_http_output_timeout
(HTTP) 和
 protocol_https_timeout_output
(HTTPS) 超时值。换而言之,如果请求是
DispatchbyURI
方法,那么将通过 RMI/IIOP 协议接收该请求,因此
protocol_http
变量无效。

然后可以使用带有 CEEDUMP 或 NTHREADS 选项的 IPCS verbexit LEDATA 获取该请求的堆栈跟踪。


指示主题类型的图标 参考主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_analyzetimeout
文件名:rtrb_analyzetimeout.html