[分享]TUXEDO编程简介2_MQ, Tuxedo及OLTP讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MQ, Tuxedo及OLTP讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3146 | 回复: 0   主题: [分享]TUXEDO编程简介2        下一篇 
barry
注册用户
等级:中校
经验:1534
发帖:236
精华:2
注册:2012-1-13
状态:离线
发送短消息息给barry 加好友    发送短消息息给barry 发消息
发表于: IP:您无权察看 2014-11-13 14:47:04 | [全部帖] [楼主帖] 楼主

一、首先设置合理的操作系统核心参数!!

#用tmunloadcf > generated.ubb 可以得出目前配置得UBB文件所有得参数值(没有设置的有缺省值)
#用tmloadcf –c或tmboot –c可以计算出当前UBB配置的Tuxedo启动最少要占用的系统IPC资源。
Ipc sizing (minimum /T s only) ...
Fixed Minimums Per Processor
SHMMIN: 1
SHMALL: 1
SEMMAP: SEMMNI
Variable Minimums Per Processor
SEMUME,           A                             SHMMAX
SEMMNU,           *                               *
Node                    SEMMNS  SEMMSL  SEMMSL  SEMMNI  MSGMNI  MSGMAP  SHMSEG
------                  ------  ------  ------  ------  ------  ------  ------
KF_FENGM                    65       8      60   A + 1      37      74    220K
where 1 <= A <= 8.
SEMMNS
Maximum number of semaphores in the system. The minimum requirement for SEMMNS is
MAXACCESSERS - MAXWSCLIENTS + 13
SEMMNI
Maximum number of active semaphore sets
SEMMSL
Maximum number of semaphores per semaphore set. SEMMNI and SEMMSL are commonly chosen so that their product equals SEMMNS. The BEA Tuxedo system does not perform semaphore operations on semaphore sets; however, it attempts to allocate as many semaphores per semaphore set as possible
SEMMAP
Size of the control map used to manage semaphore sets. SEMMAP should be equal to SEMMNI
SEMMNU
Number of undo structures in the system. Because an undo structure is needed for each process that can access the Bulletin Board, SEMMNU must be at least as large as SEMMNS
SEMUME
Maximum number of undo entries per undo structure. The 1 suffices.


二、BEA Tuxedo配置文件UBBCONFIG

UBB配置文件分成*RESOURCES,*GROUP,*SERVER,*SERVICE,*NETWORK等若干节。DEFAULT表示该节中所有对象共有的缺省属性。

*RESOURCES
#RESOUCES节提供整个系统的基本参数。
IPCKEY   55555 (32767-262143)
#进行IPC通讯的key值
DOMAINID    unicom
#DOMAIN的ID值
MASTER      unicom1,unicom2
#指定DOMAIN中的管理主机为unicom1,运行过程中unicom1若出现问题,管理主机切换至unicom2
MAXACCESSERS  1000
#这里该值表示整个系统中单个机器上可以访问TUXEDO的最多的Client和Server的总数(可以访问 BBL的最大进程数),应大于license用户数+server数(副本应记入)。该字段会被MACHINE部分的MAXACCESSERS覆盖。
#系统核心参数中SEMAPHORE的数目(SEMMNS)要大于这里的MAXACCESSERS数目,而ipc消息个数(MSGMAX)应大于MAXACCESSERS数+所有带REPLYQ的SERVER的个数。
MAXSERVERS  80
#最大的server数(副本应记入)
MAXSERVICES 200
#最大的service数(多个server重复记入)
MAXGTT  20
#系统最多的并发的全局交易数目
MODEL  MP
#表示cluster方式,否则为SHM
OPTIONS         LAN,MIGRATE
#多机cluster方式时必须指定为LAN方式,MIGRATE表示可以以组为单位进行机器间SERVER的迁移。
LDBAL       Y
#允许负载均衡
SCANUNIT    10
#SCANUNIT 是BBL在所有服务请求中定期扫描以寻找超时的交易和被阻塞德调用和德间隔时间(秒)。这个参数指定BBL扫描间隔时间的基本单位, 它会影响在tpbegin中指定的交易超时时间和用BLOCKTIME指定的请求阻塞超时时间的精确程度。SANITYSCAN, BBLQUERY, DBBLWAIT, BLOCKTIME等参数都是SCANUNIT的倍数,而不是实际秒数。而作为时间单位SCANUNIT必须是5的倍数,并且满足0<SCANUNIT<60。
SANITYSCAN      12
#SANITYSCAN的值指定在每个MACHINE上BBL自动检测所有进程的时间间隔,以SCANUNIT为单元。缺省值满足(SCANUNIT*SANITYSCAN)约为120秒。
DBBLWAIT     2
#DBBLWAIT的值指定DBBL扫描BBL时等待所有BBL应答的最大时间,以SCANUNIT为单元,即超过DBBLWAIT*SCANUNIT(秒)就超时。每一次DBBL将请求转发给它的BBL时,BBL会在请求返回结果之前先回复一个肯定的应答。这样可以定时检测死掉或不正常的BBL。缺省值满足(SCANUNIT*DBBLWAIT)的值等于SCANUNIT和20秒两者之间的最大者。
BBLQUERY    30
#BBLQUERY指定DBBL对所有BBL进行状态检查的时间间隔,它也是以SCANUNIT为计算单位。如果DBBL的状态询问没有回答,该BBL就被‘隔离’了。缺省值满足(SCANUNIT * BBLQUERY) 约为 300秒。
BLOCKTIME   6
#BLOCKTIME指定在阻塞队列中的被阻塞请求的超时时间(包括客户端从tpinit到tpterm的等待时间),以SCANUNIT为计算单位。缺省值满足(SCANUNIT * BLOCKTIME) 约为60秒。
*MACHINES
DEFAULT:
#该部分对各主机进行描述。
unicom2    LMID=unicom2
APPDIR = "/usr/tuxedo/apps/simpapp"
TUXCONFIG = "/usr/tuxedo/apps/simpapp/tuxconfig"
TUXDIR = "/usr/tuxedo"
UID = 17
GID = 26
MAXACCESSERS = 100
unicom1 LMID = unicom1
APPDIR = "/usr/tuxedo/apps/simpapp"
TUXCONFIG = "/usr/tuxedo/apps/simpapp/tuxconfig"
TUXDIR = "/usr/tuxedo"
UID = 17
GID = 26
MAXWSCLIENTS = 50
#unicom2, unicom1为网络主机名用hostname获得。
#LMID:Logical Machines ID 为tuxedo对主机的内部逻辑命名。
#APPDIR要求放置SERVER的可执行文件。
#TUXCONFIG为全路径的二进制配置文件,要求和环境变量TUXCONFIG相同。对于master机tuxconfig文件是由tmloadcf生成的,而非master机则是由tmboot启动后由tlisten从master机上拷贝获得。
#TUXDIR为tuxedo安装目录,要求和环境变量TUXDIR相同。
#MAXWSCLIENTS表示可连接client的最大个数。
*GROUPS
#GROUP1为组名,LMID表示该组运行的主机,GRPNO为组号,OPENINFO为该组通过XA打开RM(通常指数据库)的初始串。
GROUP1  LMID=unicom2 GRPNO=1    OPENINFO=NONE
GROUP2  LMID=unicom3 GRPNO=2 OPENINFO=NONE
*SERVERS
#这里描述应用服务器。SRVGRP的该SERVER所属组名,SRVID为服务器ID号,MIN表示该服务器CLOPT提供运行的相关参数,要求是”-A -- ….”,可以在应用服务器的srvinit函数中获得这些参数。
DEFAULT:
CLOPT="-A"
BillServer SRVGRP = GROUP1 SRVID = 1 MIN = 2 MAX = 4
RQADDR = QNAME REPLYQ = Y
CLOPT = "-A -o ./out.log –r -e ./err.log --
-p [L][low_water][,[terminate_time]][:[high_water][,create_time]]


如果MAX>1,并且使用了MSSQ(RQADDR, RQPERM)的Server可以配置-p来控制进程的增加和减少。控制算法如下:如果请求队列中的请求个数大于high_water 后超过create_time 秒,就增加该服务的一个新进程; 如果请求队列中的请求个数小于low_water 后超过terminate_time 秒, 就停止该服务的一个进程。low_water 缺省是平均每个服务进程有一个请求消息或者workload 50;high_water 缺省是平均每个服务进程有两个请求消息或者workload 100。create_time 缺省最小是50秒, and terminate_time 缺省最小是60秒。
注意:
使用TUXEDO的服务进程池时,用户自己在程序中如果用alarm()等系统调用来停止进程是不起作用的,但也不会报错。
[L] 标记意味着增减服务进程基于负载而不是请求队列的长度。仅用于SHM模式下并且LDBAL=Y,否则会报错 (LIBTUX_CAT:1542) ,服务进程也不会增减。 

WSL    SRVGRP=GROUP2 SRVID=1
CLOPT = "-A -- -n //130.36.0.103:8889 -m 3 -M 10 -x 10 -T 10"
#WSL用于和client端进行连接。-n 表示出接入点为IP:PORT方式,-m –M 表示最小和最大启动多少个WSH和前端通讯,-x则表示一个WSH和几个client端连接。-T 10表示如果client端和server连接后10分钟内没有交易请求则关闭连接。
*SERVICES
#不要求将所有的service在这里描述,当某个service有特别参数时才在SERVICE节中说明。
TOUPPER
LOAD = 60          // 负载,当LDBAL=Y时有用
PRIO = 80          // 服务在请求队列中的优先级
TRANSTIME = 120        // 交易时间
SVCTIMEOUT = 600       // 服务超时时间
*NETWORK
#NETWORK节对多机之间如何进行网络连接进行描述。
#cluster方式下要求先启动tlisten。事实上,对于非master机启动应用服务器是由tlisten完成的。
#tlisten的启动方式为
#unicom1: tlisten –l //130.36.1.101:8891
#unicom2: tlisten –l //130.36.0.102:8891
#NADDR指定网络连接的接入点。
#NLSADDR则指定tlisten的接入点。
#BRIDGE则指TCP连接所用的设备文件。


--转自 北京联动北方科技有限公司




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论