5--tuxedo服务拥堵应急处理

Tuxedo服务出现拥堵后应急处理

步骤1：检查是否有锁或者大消耗的sql

查看数据库上是否有锁或者消耗资源比较大的sql语句。如果有及时通知DBA做相应处理。处理过后，用pq命令查看队列是否有下降。如果没有大的改善，就进入下面步骤。

步骤2：清除堵的队列

据经验来看这个方法是目前维护生产系统代价最小又行之有效的方法，已经写好相应的维护的脚本。出现服务堵塞时，先执行pq命令查看堵塞的队列，效果如下：

每1秒运行1次，按任意键退出!

tmadmin - Copyright (c) 2007-2008 Oracle.

Portions * Copyright 1986-1997 RSA Data Security, Inc.

All Rights Reserved.

Distributed under license by Oracle.

Tuxedo is a registered trademark.

qcscrm1l1serve qcscrm4l1_2 9 100 2 0.3 ngbss tamcbs1l2serve tamcbs4l2 5 100 2 0.3 ngbss tamcbs1l1serve tamcbs4l1 9 100 2 0.5 ngbss tcscrm1l1serve tcscrm1l1 9 100 2 1.9 ngbss qcscrm1l2serve qcscrm3l2 9 100 2 2.0 ngbss qcscrm1l2serve qcscrm1l2 9 150 3 1.7 ngbss tcscrm1l1serve tcscrm4l1 9 200 4 1.5 ngbss tcscrm1l1serve tcscrm3l1 9 200 15 1.6 ngbss TMS_ORA GRPCCCRM2_+ 5 300 15 0.5 ngbss

--------- ------------------- --------- -------- -------- -------

> Prog Name Queue Name # Serve Wk Queued # Queued Ave. Len Machine

以上图为例，服务tcscrm1l1server有点堵塞，可以执行维护脚本quick.sh(在每台tuxedo 应用用户下都有)。执行脚本提示如下：

1---全停,tmshutdown -y

2---全启,tmboot -y

3---单停某个服务，tmshutdow -s *

4---单启某个服务，tmboot -s *

5---单停某个服务组，tmshutdow -g *

6---单启某个服务组，tmboot -g *

7---单停某个组下的某个服务，tmshutdow -g 组名 -s 服务名

8---单启某个组下的某个服务，tmboot -g 组名 -s 服务名

9---紧急停全部服务，强行释放所有资源tmipcrm -y

a---重启拥堵的队列psr -q 队列名：

t---重启某个域的数据库连接服务tmshutdown -T 组名：

q---退出！

输入a，选择重启拥堵的队列，再按提示输入队列名，就是pq命令结果展示的第二列，如上图中的tcscrm3l1，就开始清除拥堵的队列。

如果拥堵服务是数据库连接TMS_ORA，执行quick.sh脚本选择t，按提示输入数据库连接组名，如上图中的GRPCCCRM2_+ ，但要去掉_+符号，也就是输入GRPCCCRM2

一般清除数据库上的分布式锁或者死锁，拥堵队列就能解决问题。如果服务大面积僵死必须得整个重启（很少出现），进入下面步骤。

步骤2：重启第一批tuxedo服务

服务已经堵死需要重启，分批进行，第一批重启的tuxedo：

全业务tuxedo中的：133.160.90.31tuxapp1和133.160.90.31tuxapp2

接口tuxedo中的：133.160.91.39tuxapp1和133.160.91.39tuxapp2

重启相关命令：

正常停服务的命令：tmshutdown -y –w1;

强行停服务的命令：先执行tmipcrm -y （释放内存），再强行杀掉进程 kill -9 -1 。（服务停很久停不下来才用这种方式）

启服务的命令：tmboot –y

步骤3：对第一批tuxedo服务进行预热

对第一批重启的tuxedo进行预热

?先将这批4台tuxedo的JSL服务停掉，阻断部分服务调用，执行命令：

tmshutdown –s JSL

?再执行预热脚本，最好执行脚本3遍，第一遍约15分钟，第二遍约3分钟，第3遍约1分钟。

命令如下：

cd $HOME/tools/param

nohup ./paramload.sh &

预热最新的脚本，提高并行度，缩短预热时间，命令如下：

cd $HOME/tools/param

gathercrm.sh

gatheract.sh

最好执行如上2个脚本2遍，第一遍约5分钟，第二遍1分钟。

ps –ef|grep act4.sh|grep –v grep|wc -l，如果没有进程说明预热完成。

?预热完成后，记得将JSL服务启起来，然后进行第二批tuxedo操作，命令：

tmboot –s JSL

步骤4：重启第二批tuxedo服务

第二批重启的tuxedo：

全业务tuxedo中的：133.160.90.32tuxapp1和133.160.90.32tuxapp2

接口tuxedo中的：133.160.91.40tuxapp1和133.160.91.40uxapp2

重启的命令同步骤2。

步骤5：对第二批tuxedo服务进行预热

对第二批重启的tuxedo进行预热

预热的步骤和命令同步骤3。

步骤6：通知相关接口重启服务和WTC

通知相关接口，重启一下相关服务或者WTC连接。

OCS接口，尤其是OCSDOM的WTC连接已经多次遇到tuxedo重启后WTC连接失效

但在weblogic控制台上看，连接正常，但所有OCS的号码在客户资料综合查询菜单都会报错。需要特别注意重启WTC。

步骤7：检查BPM

?检查BPM是否正常，看工单是否有积压。

?用pq命令查看队列，用psr命令查看是否有服务调用BPM。

?在crm区域1库上执行如下sql查看各域是否有工单积压。

SELECT COUNT(*) from uop_crm1.tf_b_trade t where t.next_deal_tag='0'AND

t.subscribe_state='0'AND t.exec_time

SELECT COUNT(*) from uop_crm2.tf_b_trade t where t.next_deal_tag='0'AND

t.subscribe_state='0'AND t.exec_time

SELECT COUNT(*) from uop_crm3.tf_b_trade@uqry_sel_to_hacrmdb22 t where

t.next_deal_tag='0'AND t.subscribe_state='0'AND t.exec_time

SELECT COUNT(*) from uop_crm4.tf_b_trade@uqry_sel_to_hacrmdb22 t

where t.next_deal_tag='0'AND t.subscribe_state='0'

AND t.exec_time

?如果有大量工单积压，则需重启BPM，命令：

停服务：tmshutdown –y

启服务：tmboot –y

?再执行上面的sql查看工单处理速度是否正常。

重启后最常见问题及可能原因：

问题：首页认证或者客户资料查询或办理其他业务时，一会儿正常一会儿报错。

可能原因：

1.最可能的是预热不充分，重启后最好多预热几次。（多次遇到这种情况）

2.Tuxedo重启后可能会导致外部接口的一些WTC连接失效，而且有的是在weblogic端查看一切正常而实际上并没有连上tuxedo，就可能出现办理业务一会儿正常一会报错。（OCS接口遇到过此种情况）。查看weblogic服务有没有连上tuxedo的命令如下：

dmadmin

pd –d CRMTUX_?

（上面的?指dbb里配置的tuxedo端服务名，如果不是很清楚，可以在每台tuxedo应用的etc 目录下的dbb文件中查看，如31tuxapp1 对应的是CRMTUX_1，31tuxapp2 对应的是CRMTUX_2）