1. 概述
11月15日上午8点半开始tuxedo ULOG日志开始频繁的抛出一个关于GWTDOMAIN的告警,并伴随部分服务调用失败,下午4点左右大面积WTC调用tuxedo域服务失败,重启整个tuxedo系统,故障恢复。10月份也出现过一次这样的情况。
2. 问题分析
15日上午8点半开始报如下错误:
083303.QTBZSF2!GWTDOMAIN.2093496.1.0: LIBGW_CAT:1023: ERROR: Service request <GPSERV> from remote site <wtc6_pay1_230> failed:"" gwerrno(402018)
083303.QTBZSF2!GWTDOMAIN.2093496.1.0: LIBGW_CAT:1023: ERROR: Service request <GSTAFF> from remote site <wtc6_pay2_230> failed:"" gwerrno(402018)
083303.QTBZSF2!GWTDOMAIN.2093496.1.0: LIBGW_CAT:1023: ERROR: Service request <GSTAFF> from remote site <wtc6_pay2_230> failed:"" gwerrno(402018)
083303.QTBZSF2!GWTDOMAIN.2093496.1.0: LIBGW_CAT:1023: ERROR: Service request <GSELECT> from remote site <wtc6_pay1_230> failed:"" gwerrno(402018)
083303.QTBZSF2!GWTDOMAIN.2093496.1.0: LIBGW_CAT:1023: ERROR: Service request <MQPAYSTX> from remote site <wtc6_pay1_230> failed:"" gwerrno(402018)
持续时间为:8:32-8:34,之后没有报上面的错误,直到14:31有开始频繁的报错,此次报错一直持续到15:59重启系统,在这两个阶段的报错中,调用失败的远程域主要有:(其中前三个域调用失败比较多)
wtc6_pay2_230 wtc6_pay1_230 wtc6_abm2_230 bank_zzjf terminal2 qsbill_wap140b qs_billhbtlc6_1 jhbank qsbill_136b qsbill_sms140b wtc6_abm2_230 qslogin_sms140b bill65_sgw2 terminal terminal2 wtc_ss_hb_a2 wtc_ss_hb_a2
远程域通过本地域的GWTDOMAIN调用本地服务失败,错误号为402018,在metalink上查找这个错误没有任何消息;但查到gwerrno(402017)错误表示调用的service不存在,GWTDOMAIN会抛出上面这个错误;如果本地的server的队列满了,会抛出错误号为gwerrno(402019)的错误,我们碰到的不是这两个错误,于是开SR,800工程师给我们的解释如下:
GWTDOMAIN在处理请求是内部有一个context的资源,如果这个资源被占满了,那么就会抛出gwerrno(402018)错误,同时请求也不能被转发到相应的server进行处理。导致这个资源被占满的原因通常是因为本地的服务积压,只要正在处理还没有返回的请求都会占用这个资源,如果已经返回了就不会占用了。
通过oracle论坛找到这个GWTDOMAIN的context资源上限是10000,但根据管理员反映当时查看pq队列最多也就有几百的排队,但到了下午排队也消失了,如果按照800的解释正在处理的请求也占用这个context资源,那么理论上达到这个上限也有可能。但是,和这个tuxedo domain同样的配置、负载更高的另外一个域却没有出现过这样的情况。
3. 问题建议
1) 注意监控server队列排队情况,并使用psr查看各server的运行状态,是否存在服务积压。特别注意在本次出现问题时调用失败比较多的三个域wtc6_pay2_230 wtc6_pay1_230 wtc6_abm2_230所调用的服务以及它们的队列
2) 再次出现同样问题时,可尝试重启与域相关的3个进程DMADM GWADM GWTDOMAIN,注意启动的时候顺序启动上面三个进程,停止的时候倒序停止,如果不起作用则需要重启整个域
3) 增加一组新的网关进程组,有两个网关进程分担所有远程域的服务请求。但要注意如果单单增加一组网关,而远端的网关不做对应的修改,这个增加没有意义;需要把远端的网关配置成负载均衡的模式才有意义,需要把所有的远端的网关上的服务配置成负载均衡模式,否则有可能某些处理比较慢的请求有可能会配置到一个网关上,这样就不能解决问题了。或者根据业务划分也可以。
4. 远程域重名问题
在ULOG中发现大量如下信息:
000013.QTBZSF2!GWTDOMAIN.1843582.1.0: LIBGWT_CAT:1553: INFO: New connection from domain <dlsA_qscharge_g> accepted, drop old connection!
000013.QTBZSF2!GWTDOMAIN.1843582.1.0: LIBGWT_CAT:1553: INFO: New connection from domain <dlsA_qscharge_c> accepted, drop old connection!
000013.QTBZSF2!GWTDOMAIN.1843582.1.0: LIBGWT_CAT:1553: INFO: New connection from domain <ycbillhb1w130_2> accepted, drop old connection!
上面信息是由于存在重名的远程域连接本地域时,一个域会把另一个域的连接踢掉,被踢掉的域会根据当前域配置里的RETRY_INTERVAL=10参数每隔10秒重新连接,这样又把之前的域连接踢掉,这样反复重连对服务调用的性能会造成一定的影响,同时也不便于域管理。
可通过在本地域设置GW_VALIDATE_HOST=YES环境变量,验证发起连接请求的远程域IP,如果该IP没有在域配置文件中指定,则禁止连接。设置完环境变量后,会在下次tuxedo启动的时候打出LIBGWT_CAT:1612:INFO: Validate host feature is enabled by xxdom,出现上述信息表示环境变量设置成功。
不过这种方式还是存在弊端的,如果这两个同名的远程域是在同一台主机上并共用一个IP时,上面设置的参数则不会起作用。所以建议我们的管理员还是根据日志中报的同名域名称,找到它们并重新赋予新的域名称。