<P></P><P>摘要：   本《功略》集中了TUXEDO应用中，可能涉及到的所有时间参数，并分别对其进行详细描述，不但对其出处、取值等基本属性进行查证，而且，通过分析其内在的控制机制，给出设置建议，以期能够达到透彻理解、方便查阅、准确使用的目的。 1 前言   金融、电信等众多行业的综合营业系统中，广泛使用了TUXEDO交易中间件，用来处理大量并发的联机事务处理（OLTP）业务。典型的OLTP业务，每笔业务的信息量较小，而且，具有一定的实时性，对时间的要求非常严格。   TUXEDO，联系着DATABASE和客户端软件，凭借其多层次的超时控制机制，达到客户端快速响应，服务器端稳定可靠的效果。   TUXEDO的多层次的超时控制机制中，涉及到的时间参数不少于10个，再加上与之紧密联系的DATABASE中的几个超时参数，确实比较复杂。遗憾的是，目前还没有的专门的文档对它们进行详细说明，而是分散在不同的专题中分别说明，而且，不同的专题中，解释的详细程度也不一样，在查阅过程中，多有不便。   本文试图将这些参数集中起来，对每一个都加以详细说明，并试图解释每个参数存在的原因。大部分参数时间长短的设置，除个别外，基本没有固定的模式，只要了解它们的具体含义，并结合具体应用系统的实际要求，相信大家都能够作出合理的配置。 2 全功略解读 2.1 SCANUNIT 2.1.1 参数出处   UBBCONFIG配置文件 -> RESOURCES -> SCANUNIT 。 2.1.2 时间单位   秒,且必须为5的倍数。 2.1.3 取值范围   大于0小于等于60中5的倍数，即｛5，10，15，20，25，30，35，40，45，50，55，60｝。 2.1.4 默认取值   10 。 2.1.5 用途解释 ⑴   这个参数大家都会用，比较好理解，TUXEDO中，BBL是用来对Bulletin Board进行管理和监控的系统进程，它基于时间片的轮询方式，时间片的大小就是SCANUNIT的值，SCANUNIT是Tuxedo对系统进行管理的最基本时间单位。每隔SCANUNIT，BBL对Bulletin Board进行一次检查，看看有没有超时的事务或阻塞的服务请求。后面讲到的很多时间参数都是以SCANUNIT为单位。 2.1.6 超时后果   仅仅是个轮询时间单位而已，到时间就轮询，如此而已。 2.1.7 设置考虑   作为一个涉及到整个TUXDO系统的基本单位时间，如果业务需要，对时间参数控制比较严格，设置为5也不算小。如果系统业务对时间要求不严格，那就大点儿，60也没什么不可以；毕竟频繁轮询是要耗费更多系统资源的，而任何对资源的不必要的消耗都是浪费。 2.2 SANITYSCAN 2.2.1 参数出处   UBBCONFIG配置文件 -> RESOURCES -> SANITYSCAN 。 2.2.2 时间单位   SCANUNIT 。 2.2.3 取值范围   1 ～32767 。 2.2.4 默认取值   大约120/SCANUNIT。 2.2.5 用途解释 ⑵   进行系统健全性检查，主要包括Server进程状态和Bulletin Board数据结构，检查Server进程是否存活，如果已经不存在，会清理Bulletin Board中相应的数据项及IPC资源，并根据参数配置决定是否重新启动，如果设了RESTART=Y，所占的Message Queue不会被清除，Queue中的Request得到保留，仍会被处理。如果是MP模式，BBL还会给DBBL发状态消息。 2.2.6 超时后果   仅仅是个系统健康检查的间隔时间而已，到时间就检查，如此而已。 2.2.7 设置考虑   作为一个涉及到整个TUXDO系统健康检查的间隔时间，如果系统处在一个稳定的运行环境中，网络、数据库、应用都很稳定，那这个参数可以大一些；如果运行环境不稳定，系统繁忙，而且Server进程经常因异常（如超时）而死掉，那就设置小一些。设置的原则和SCANUNIT一样：不要随意浪费系统资源。 2.3 BBLQUERY 2.3.1 参数出处   UBBCONFIG配置文件 -> RESOURCES -> BBLQUERY。 2.3.2 时间单位   SCANUNIT 2.3.3 取值范围 ⑶   BBLQUERY必须大于等于SANITYSCAN，tmloadcf 时会强制检查，如果设的值小于SANITYSCAN，tmloadcf会自动调整为SANITYSCAN。 2.3.4 默认取值   大约300/SCANUNIT。 2.3.5 用途解释 ⑷   BBL检查，在MP模式下，BBL会每隔一段时间都发送了" I am ok "心跳信息给DBBL，这个间隔就是BBLQUERY。 2.3.6 超时后果 ⑸   如果DBBL在规定时间间隔内没有收到某个BBL的信息，DBBL它会主动发送Request给那个BBL，判断其是否正常。（如果等了DBBLWAIT后仍然没有回复，DBBL会认为那台机器有问题，然后，将其隔离。） 2.3.7 设置考虑   此设置仅仅在MP模式下才起作用。   在MP模式下，如果TUXEDO系统需要对不稳定的运行环境可能发生的故障作出快速的反应，那么BBLQUERY要设置小一些，让系统快速的自我检查。考虑网络传输时间、系统反应速度等因素，网络速度越慢，系统负载越重，取值越大；反之亦然。   如果系统运行环境很稳定，利用其默认值即可，甚至可以更大数值。 2.4 DBBLWAIT 2.4.1 参数出处   UBBCONFIG配置文件 -> RESOURCES -> DBBLWAIT。 2.4.2 时间单位   SCANUNIT。 2.4.3 取值范围   大于0。 2.4.4 默认取值   1和20/SCANUNIT中的较大者 。 2.4.5 用途解释 ⑹   如果DBBL在规定时间间隔BBLQUERY内没有收到某个BBL的"I AM OK"信息，它会发Request给那个BBL，其等待回复的时间就是DBBLWAIT。 2.4.6 超时后果 ⑺   DBBL等了DBBLWAIT后仍然没有回复，DBBL会认为相关BBL的机器有问题，然后，将其隔离（partation）。 2.4.7 设置考虑   此设置仅仅在MP模式下才起作用。   在MP模式下，考虑网络传输时间、系统反应速度等因素，网络速率越大，系统负载越轻，此数值越小；反之亦然。 2.5 BLOCKTIME 2.5.1 参数出处   UBBCONFIG配置文件 -> RESOURCES -> BLOCKTIME。 2.5.2 时间单位   SCANUNIT。 2.5.3 取值范围   大于0。 2.5.4 默认取值   大约60/SCANUNIT。 2.5.5 用途解释   Client端阻塞请求（Blocking call）服务的超时值，BBL发现有超时的Request时，会给相应的Client端发超时信息。   此参数仅仅在"阻塞请求"的情况下起作用，因此，理解它，关键要理解什么是阻塞请求（Blocking call）？习惯上，我们将"阻塞请求"理解为"同步请求"，将"异步请求"理解为"非阻塞请求"，是源于将"<发送请求－得到结果>"这一过程看成为一个整体。如果是整体的同步操作，就认为是"阻塞请求"；如果是分开异步的操作，就认为是"非阻塞请求"。   其实，异步操作中，同样存在"阻塞请求"，tuxedo中，tpacall和tpgetrply这两个异步操作各自本身就是"阻塞请求"，tpacall是将请求发送到请求队列，tpgetrply是将从结果队列中取出结果，如果没有特殊的设置，这两个操作本身都是阻塞的，BLOCKTIME将起作用。   以Request/Reply方式为例，将成功发送请求的时长设置为T1，将请求处理的时长(含排队等待)设置为T2,将成功取得结果的时长设置为T3，那么在下面不同的情况下，将触发BLOCKTIME，引起超时：   （1） tpcall（）不在transaction中，flag为0，当T1+T2+T3 > BLOCKTIME时，发生超时 ;   （2） tpcall（）不在transaction中，flag为TPNOBLOCK，只有当一次调用即成功完成T1阶段发送请求的任务后，T2+T3 > BLOCKTIME时，发生超时 ;   （3） tpacall（）不在transaction中，flag为0，当T1 > BLOCKTIME时，发生超时 ;   （4） tpgetrply（）不在transaction中，flag为0，当T2+T3 > BLOCKTIME时，发生超时 ;   （5） tpcall，tpacall,tpgetrply,在其他任何情况，BLOCKTIME都将不起作用。   （6） 如果请求处于事务交易（transaction）中，此参数不起作用，取代它的是 TransactionTimeOut。 2.5.6 超时后果   在上面描述的四种情况下，Server端 BBL返回Client端超时错误：tperrno ＝ 13 （TPETIME）。同时，client端和Server端已经建立的联接不受任何影响，继续保持联接。 2.5.7 设置考虑   此参数涉及整个TUXEDO系统，不能够直接适应业务系统中不同场合的不同时间等待要求，而且在应用过程中，存在误差，不适合进行精确到秒的时间控制。   准确有效的使用这个参数，需要考虑好以下几个问题：   （1） 应用中是否完全依赖这个参数进行时间控制？   （2） 有哪些业务依赖这个参数进行时间控制？   （3） 平衡各种业务，此参数设置为多少？   （4） 除此参数外，是否需要利用其他的超时控制机制？ 2.6 WSL CLOPT [-T Client_timeout] 2.6.1 参数出处   UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-T"。 2.6.4 默认取值   0 ，意味着无限等待时间。 2.6.5 用途解释 ⑻   系统允许的Client静默时长，即Client和WSH建立联接后，如果在此指定的时间内客户端没有发送任何请求，WSH会自动回收与此Client端相关的资源。 2.6.6 超时后果 ⑼   WSH会自动释放和这个Client端的联接，并将此Client在Bulletin Board中的数据项清空，RollBack它未完成的事务 。 2.6.7 设置考虑   此参数的设置目的，主要是从Server的角度进行考虑，防止在Client端意外失效的情况下仍然耗费Server端的资源。   如果设置太小，那么频繁的检测同样要消耗Server端一定的资源，而且，在使用长联接的系统中，系统空闲时，容易造成已经建立的长联接频繁的释放，影响正常业务的提供。   如果设置为0，不管发生什么状况，哪怕是Client端系统真的崩溃了，也不会触发此超时，这将造成Server端资源的无谓浪费。   建议：在业务负载不均衡的长联接业务系统中，根据业务实际空闲时间，适当加大此数值。 2.7 WSL CLOPT [-t timeout] 2.7.1 参数出处   UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-t"。 2.7.2 时间单位   SCANUNIT。 2.7.3 取值范围   大于0。 2.7.4 默认取值   非安全应用为3，安全应用为6 。 2.7.5 用途解释   建立联接时长，指workstation Client建立与server端WSH建立联接允许的最长时间，因为非安全应用建立联接时不需要进行用户校验等步骤，因此，建立联接需要的时间较短。同理，安全应用需要的时间较长。 2.7.6 超时后果   建立联接失败。 2.7.7 设置考虑   设置此参数，要分析业务系统中，网络带宽因素、用户验证的复杂程度等。 2.8 WSL CLOPT [-I init_timeout] 2.8.1 参数出处   UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-I"。 2.8.2 时间单位   秒。 2.8.3 取值范围   大于0。 2.8.4 默认取值   60 。 2.8.5 用途解释 ⑽   WorkStation Client端和后台建立联接的超时参数值。   （注：感觉上此参数和 WSL CLOPT [-t timeout]功能类似） 2.8.6 超时后果   不确定，现有的文档没有一点儿解释。按照字面解释，应该是tpinit的超时时间，但是，在tpinit所有的错误中，只有TPESYSTEM可能承担这个超时后果，而且仅仅是可能。 2.8.7 设置考虑   在使用过程中，没有感觉到这个参数的存在，也从来没有专门设置过。 TOP tmadmin 超级版主 Rank: 8Rank: 8 发短消息 加为好友 当前离线 2# 大 中 小 发表于 2008-10-28 11:48 只看该作者 2.9 WSL CLOPT [-N network_timeout] 2.9.1 参数出处   UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-N"。 2.9.2 时间单位   秒。 2.9.3 取值范围   大于等于0。 2.9.4 默认取值   0 。 2.9.5 用途解释   网络超时，指Workstation client利用网络接收数据（receive data）的等待时间。   我们同样需要分析触发Network Timeout的不同条件。   以Request/Reply方式中的tpcall为例，将成功发送请求的时长设置为T1，将请求处理的时长(含排队等待)设置为T2,将成功取得结果的时长设置为T3，那么在如下情况下，将触发Network Timeout，引起超时：   （1） tpcall（）不在transaction中，flag为0，当 BLOCKTIME> T1+T2+T3 > NetworkTimeout时，触发此超时 ;   （2） tpcall（） 在transaction中，flag为0，当TranactionTimeout> TI+T2+T3 > NetworkTimeout时，触发此超时 ;   （3） tpcall（）不在transaction中，flag为TPNOBLOCK，只有当一次调用即成功完成T1阶段发送请求的任务后，当 BLOCKTIME> T2+T3 > NetworkTimeout时，触发此超时 ;   （4） tpcall（）在transaction中，flag为TPNOBLOCK，只有当一次调用即成功完成T1阶段发送请求的任务后，当 TranactionTimeout> T2+T3 > NetworkTimeout时，触发此超时 ;   （5） tpcall（）不在transaction中，flag为TPNOTIME，当 T1+T2+T3 > NetworkTimeout时，触发此超时 ;   （6） tpcall（）在transaction中，flag为TPNOTIME，当 TranactionTimeout> TI+T2+T3 > NetworkTimeout时，触发此超时 ;   （7） tpcall在其他任何情况，NetworkTimeout都将不起作用。   （8） 同理，可以确定NetworkTimeout在tpacall和tpgetrply中起的作用。 2.9.6 超时后果   在上面描述的六种情况下， Client端操作失败，同时，client端断开与Server端已经建立的联接。Server端已经为此Client完成的操作和分配的资源不能立刻回滚和释放，Server端需要等待前面介绍过的Client_timeout时间后，再释放相关的资源。 2.9.7 设置考虑   此参数的设置目的，主要是从Client的角度进行考虑，防止在Server端意外失效的情况下，仍然消耗Client端的资源。   设置参数，必须避免小于BLOCKTIME或TransactionTimeout的情况，因为在这种情况下，会出现业务正常等待中，联接却中断的现象，这是一定要避免的。   同时，由于此超时触发的联接中断，并不能立刻释放Server端的资源，带来业务执行过程中的不确定性，因此，此参数要谨慎使用。 2.10 SVCTIMOUT 2.10.1 参数出处   UBBCONFIG配置文件 -> SERVICES -> SVCTIMEOUT 。 2.10.2 时间单位   秒 2.10.3 取值范围   大于等于0。 2.10.4 默认取值   0，表示无限时长 。 2.10.5 用途解释   服务处理时长（Service Processing Time），表示系统允许服务处理请求的时间长度。   此参数主要是维护Server端系统安全的角度，防止由于系统异常引起的失控服务占据系统资源，阻碍正常的后续业务请求。它起到了一个清道夫的作用，将不能有效提供服务的Services清除出系统，并依靠系统的其他机制，重新产生具有活力的Services。 2.10.6 超时后果   超时后，此Service所属的Server将被系统的SIGKILL信号清除；此操作不会影响与此Server相关的其他正在运行的副本Servers。   如果系统设置SERVERS->RESTART=Y，那么，被清除的Server将立刻自动重新启动。重新启动的次数受随后介绍的MAXGEN和GRACE两个参数联合限制。   如果系统设置SERVERS->RCMD为有效命令文件，那么，在重启此Server时，将同时执行此命令，如向管理员发送通知邮件等。   如果SERVER没有RESTART＝Y设置，那么Server将不会自动重新启动。 2.10.7 设置考虑   此参数不是系统全局参数，而是涉及到单个Service，可以根据不同的Service的处理时间进行设置。由于其主要起到系统清道夫的角色，因此，建议设置为正常Service处理时长的3倍较合适，以避免清除正常运行的Service，使正常运行的业务受到影响。   如果系统运行环境基本稳定，一旦出现底层网络或数据库系统故障，不是在短时间内能够恢复，建议将此参数增大，至少为平均恢复时间，甚至可以利用默认值0，无限等待，避免此自动机制，而用人工介入的方法进行服务恢复。因为系统自动的、频繁的SIGKILL将影响到整个TUXEDO系统的稳定。 2.11 GRACE 2.11.1 参数出处   UBBCONFIG配置文件 -> SERVERS -> GRACE 。 2.11.2 时间单位   秒。 2.11.3 取值范围   0-2147,483,647。 2.11.4 默认取值   86400（24小时）。 2.11.5 用途解释   此时间参数与其他两个参数紧密相关RESTART, MAXGEN。   关联起来解释就是，当Server异常终止时，如果RESTART=Y，那么此SERVER可立即自动重新启动，这个重新启动的次数被限制为在GRACE指定的时间间隔内，重启不超过MAXGEN-1 次。   如果RESTART这个参数为N，其他的相关参数将都无效。 2.11.6 超时后果   此参数不仅仅是时间的限制，如果在GRACE时间段内，此SERVER重启次数已经达到MAXGEN-1，后续重启将不能执行。 2.11.7 设置考虑   此组参数设置的综合目的是避免运行Server无限的重启，重启次数说明了系统目前异常状况的严重程度，如果在一定时间内，Server重启次数达到了一定的数量，说明这个Server相关的资源已经出现较严重的故障，需要人工进行干预了。   另外，经过调优的生产系统是不需要自动重启的，因此，RESTART这个参数更多是应用在系统测试版本中，在正常运行的生产系统中，应该有不同参数设置，谨慎使用，因为过多的重启将有可能严重影响Server端的整体稳定性。 2.12 Transaction TimeOut 2.12.1 参数出处   tpbegin(timeout,0)。 2.12.2 时间单位   秒,且必须为SCANUINT的倍数。 2.12.3 取值范围   大于等于0。 2.12.4 默认取值   无，使用时必须明确指定。 2.12.5 用途解释   交易时长，确定交易（transaction）的持续时间，如果超过此时间，系统将返回超时错误。   分析其触发条件，分两种情况：   （1） Server端发起交易，   对Client而言，因为Client不在交易范围内，即使BLOCKTIME设置小于此参数，起有效作用的仍然将是BLOCKTIME，而不是此参数。   （2） Client端发起交易。   对Client而言，因为Client在交易范围内，此时，BLOCKTIME将失效，此参数取而代之。只要处理时间超过此参数，将触发此超时，交易处理将随时中断。 2.12.6 超时后果   相关交易将被标识为abort only。注意，仅仅是标识为abort only，而不是系统自动执行tpabort进行交易恢复。随后必须主动执行tpabort，恢复交易，保障交易完整性。如果没有执行tpabort，系统将通过其他机制，恢复交易，保障交易完整性。 2.12.7 设置考虑   此参数的主要目的是将交易处理过程限制在合理的时间范围内，如果确实是完成交易的条件不具备，系统也能够作出反应，避免系统资源的长时间占用。因此，不管交易由Client还是由Server发起，此参数都要按照业务的实际状况进行设置。如果设置为0，就基本相当于无限时长。（系统unsigned long数据类型的最大值） 2.13 TRANTIME 2.13.1 参数出处   UBBCONFIG配置文件 -> SERVICES -> TRANTIME/AUTOTRAN。 2.13.2 时间单位   秒,且必须为SCANUNIT的倍数。 2.13.3 取值范围   0-2147,483,647。 2.13.4 默认取值   30 。 2.13.5 用途解释   此参数必须与AUTOTRAN配合使用，表示不需要调用tpbegin，就可自动发起的隐含交易（AUTOTRAN implicitly transactions）处理持续时长。其实，起到与tpbegin（timeout,0）中的timeout相同的作用。   其实，AUTOTRAN这个参数更为重要，其默认值为N, 其作用描述如下：   （1） 请求发起方不在交易模式，AUTOTRAN＝Y，Service将自动发起一个交易，TRANTIME将起作用；   （2） 请求发起方在交易模式，而且，其中的标记参数（flags）不是TPNOTRAN，那么，无论AUTOTRAN如何，Service将自动加入请求方交易中，TRANTIME将不起作用；   （3） 请求发起方在交易模式，而且，其中的标记参数（flags）是TPNOTRAN，如果AUTOTRAN＝N，Service将自动加入请求方交易中，TRANTIME将不起作用；   （4） 请求发起方在交易模式，而且，其中的标记参数（flags）是TPNOTRAN，如果AUTOTRAN＝Y，Service将不加入请求方交易中，而是产生一个新的交易，TRANTIME将在新交易中起作用； 2.13.6 超时后果   与tpbegin(timeout,0)中的timeout相同。 2.13.7 设置考虑   与tpbegin(timeout,0)中的timeout相同。</P><P></P>