Tuxedo ubbconfig配置详解

/* TUXEDO配置文件指标解释 */

应用的描述信息配置在系统核心位置，用一个文件描述，通常称为ubbconfig文件，在主控机器上。整个TUXEDO系统的管理任务可以在一台机器上完成，在配置中被定为主控节点。

在运行时，这些信息被装入一段共享内存（一个IPC资源），称为公告牌（Bulletin Board—BB）；包含有配置中不同机器的信息，在这些机器上运行的服务的信息，这些服务提供的交易的信息以及其他相关信息。

客户端在运行时连接公告牌。当客户端程序调用一个交易，将根据公告牌找到合适的服务队列。

所以，公告牌是：

——供客户端寻找适当的服务运行一个交易请求

——包含应用信息：机器，服务，交易，网络等

——创建于ubbconfig文件

TUXEDO提供一个管理进程，称为BBL(Bulletin Board Liaison),包含了一个公告牌的本地拷贝和本地服务器上应用的状态。

TUXEDO提供的另一个管理进程DBBL(Distinguished Bulletin Board Liaison)，用于多服务器配置时。DBBL与BBL协同，保证所有部分的公告牌内容的一致性。

配置文件

任何TUXEDO应用系统的最基本的管理任务，是建立并维护配置文件。该文件通常称为ubbconfig文件。负责该工作的系统管理员必须很好的了解分布于各台机器上的应用服务的数据流，消息队列的构造，资源间的相互关系。ubbconfig文件可视作包含应用启动信息的容器，需编译成二进制文件tuxconfig，作为启动时的参考。

其内信息包括：

2 系统范围信息（*RESOURCES节）

2 机器信息（*MACHINES节）

2 组信息（*GROUPS节）

2 服务信息（*SERVERS节）

2 交易信息（*SERVICES节）

2 网络组信息（*NETGROUPS节）

2 网络信息（*NETWORK节）

2 路由原则信息（*ROUTING节）

当完成了ubbconfig文件后，用tmloadcf命令生成tuxconfig

另一种从ubbconfig生成tuxconfig的方法是使用图形管理界面(GAI—Graphical Administration Interface)。

// 应用的信息
*RESOURCES节包含整个应用范围的信息。本节必须在配置文件第一节，不可缺少。信息说明如下：
// 参数 意义
*RESOURCES *RESOURCES节
IPCKEY 共享内存id
UID TUXEDO管理员用户id
GID TUXEDO管理员组id
PERM TUXEDO管理员组用户的权限
MAXACCESSERS 服务端和客户端的最大进程数
MAXSERVERS 限制可以启动服务总数
MAXSERVICES 限制可以发布交易总数
MASTER 指出主控节点的逻辑名，第二个是备份节点
MODEL 应用构架，MP表示多机
OPTIONS LAN，MIGRATE表示是一个网络应用，服务可以移植到替代处理器上
SECURITY 安全级别（5个）
AUTHSVC 客户端可以通过交易“AUTHSVC”获得认证
NOTIFY DIPIN，客户端通过dip-in收到广播通知
SYSTEM_ACCESS PROTECTED，NO_OVERRIDE，应用代码不得干扰共享内存
LDBAL 设Y则进行负载均衡
MAXBUF[S]TYPE 数据缓冲类型及子类的最大数
SCANUNIT 内部时间间隔单位，单位是秒
SANITYSCAN 检索公告牌的内部时间间隔，单位是SCANUNIT
BLOCKTIME 交易超时时间，单位是SCANUNIT
BBLQUERY DBBL查询所有BLL的时间间隔
DBBLWAIT DBBL等待BBL回应的超时时间
MAXCONV 同时最大会话数
注意：本处未列出全部参数。这些系统范围内参数可以被后序节内参数超越。

*MACHINES节包含应用有关的每个处理器的信息。本节必须在*RESOURCES节后列出。
// 参数 意义
*MACHINES MACHINES节
gumby 物理处理器名，可以通过”uname –n”或节点名得到
TUXDIR TUXEDO系统软件安装位置
APPDIR 应用服务位置全路径
TUXCONFIG TUXEDO配置文件全路径
ENVFILE 环境文件全路径
ULOGPFX 应用日志文件全路径
MAXACCESSERS 本机最多处理器数，可以超越*RESOURCES节定义
MAXCONV 本机最大会话数，可以超越*RESOURCES节定义

*GROUP节包含服务组的定义。一台机器至少要定义一个服务组。如果没有定义组，管理命令tmadmin可能依然能运行。
每个组只要定义组名，映射组名的组号和逻辑机器名。组为分布式交易系统和数据依赖路由等灵活性措施提供了支持。
// 参数 意义
*GROUPS GROUP节
BANKB1 组的唯一标识符，可以是字母数字
GRPNO 组的唯一数字标识符
LMID 组所在的机器

ubbconfig的*SERVERS 节包含的是服务进程的信息。本节中每一个入口代表一个应用启动时加载的服务。这些信息包含服务名，命令行参数，服务环境，重启动等等。由于每个服务功能各不相同，其配置参数也因此相同或相异。
参数 意义
*SERVERS SERVER节，列出所有服务程序
DEFAULT: 本处列出的参数为其下列出的服务的缺省值，但可以被单列条目替代相应值
RESTART 如果设成Y，则服务可以重启动
MAXGEN 在GRACE定义时间之内，服务可以重启动MAXGEN次
GRACE 周期，单位是秒
RCMD 每次服务重启动，本处定义的脚本或命令被执行
ENVFILE 列有环境变量的文件，在交易启动前设入环境
TLR 一个服务名，用buildserver建立，应在APPDIR或$TUXDIR/bin
SRVGRP 服务属于一个在*GROUPS节中定义的服务组；如果需要移植服务，也可以定义在多个组中。
SRVID 服务组中代表服务的唯一值
MIN 最少在启动时启动的服务数
MAX 运行时，最多可以起的实例数
CLOPT 跟随服务启动的其他参数
-A 服务内建交易全发布
–r 指定服务记录时间戳，用于以后计算交易处理时间
-e 定义标准错误重定向文件
-o 定义标准输出重定向文件
-- TUXEDO参数和服务特定参数的分隔符
… 传给tpsvrinit()的参数
SYSTEM_ACCESS 设定后，应用错误不干扰公告牌
RQADDR 当设定此项后，所有本服务的实例都使用相同的请求队列。这是在应用中设置MSSQ（Multiple Server Single Queue）的方便办法，可以改善处理流量。任何时候，所有MSSQ集中的实例发布相同的交易集。
XFER 另一个服务
REPLYQ 设成Y，则服务又作为一个MSSQ集配置，任何其中的交易调用其他交易，就建立一个单独的回应队列。

*SERVICES节提供了应用的特殊交易的信息。包括负载平衡（LOAD）和数据缓冲类型检查（BUFTYPE）。如果全部都是缺省值则本节可以省略。
参数 意义
*SERVICES 交易节
# 注释行符号
大写字母 交易名，由应用服务提供
BUFTYPE 任何向该交易的请求，数据应该是此处定义类型
GROUP 交易所在服务所在的组
LOAD 负载因子，表示处理请求的时间，用于计算负载平衡
PRIO 优先级

生成TUXCONFIG文件

UBBCONFIG文件是一个可以编辑成需要的应用配置的文本文件。但是，/T在实际应用上读取的是二进制TUXCONFIG文件用于操作。命令tmloadcf可以把UBBCONFIG文件转化成TUXCONFIG文件。

tmloadcf命令接受以下4个参数：

-c 计算运行应用需要的IPC资源，该信息将提供给管理员，用于在各机器上配置资源。

-n 进行语法检查并不生成TUXCONFIG。

-b 控制TUXCONFIG占用的物理页数。

-y 无条件覆盖TUXCONFIG

环境变量TUXCONFIG必须设定指向二进制TUXCONFIG文件。

在安全要求高的应用中，tmloadcf不能从标准输入接受，环境变量APP_PW必须包含应用密码。

tmunloadcf将TUXCONFIG转换成ASCII格式用于检查。该工具读取环境变量TUXCONFIG指向的文件。输出包含所有的参数，包括TUXEDO设定的缺省值，是UBBCONFIG文件的一个超集。

请你把NETWORK这个section也添上，如果能够说明一下服务在网络上的情况的配置。

情况一：服务在两台机器上，一台UNIXWARE711,另一台在WIN200，采用MP模式。

情况二：主服务在UNIXWARE上，另一台用作BACKUP，也采用MP模式。

谢谢。

另外问一下，domainid是干什么的？

怎么设置管理员的UID,GID,perm。这个管理员是系统的一个用户吗？

我只知道在windows NT下面，UID指定为0。

domainID与域有关。

你可以看看与dmloadcf命令相关的文档帮助理解。

似乎这个domain和NT下的DOMAIN是不一样的吧，

tuxedo这个平台好多的概念啊

UID和GID是你服务以哪个用户和组运行，联合PERMS可以判断执行权限，不置为本用户。

Windows NT操作系统的用户和组同Unix区别较大，具体值的影响不详

Domain是在Tuxedo的架构中，可以共同负载均衡，迁移，备份等功能的一组机器，勿要同Group混淆。

与Windows域无关。

请问对这几个参数的设置，各位有什么经验

我的MAXACCESSERS已经设到2000了，还要报

我的主机是compaq的Es40 4C8G  只跑tuxedo服务

终端数在400个左右

加大MAXACCESSERS、MAXSERVERS、MAXWSCLIENTS：

MAXGTT你还用不到！

如果按1.1的话

那我不是还要减小

我已经设到2000了

搞不懂

报错的时间一般在业务比较繁忙的时候

我们是电信业务，1号左右缴费客户一多，服务器就狂报上面的错误，真是郁闷死了。

你的LICENSE如果小的话，MAXWSCLIENTS = 1.1*users

MAXACCESSERS = 1.1*(MAXWSCLIENTS+MAXSERVERS)这几个设的大也没有用的，因为你连接一个就要占用一个LICENSE的，如果并发多的话就会出现这样的情况，一种方式是在买多的LICENSE，一种方式是用多线程写程序，这样可以在一个CONTEXT里放几个线程，这种情况就是算一个LICENSE，不过BEA工程师，不建议写多线程的程序，不过到是在BEA的文档里有多线程的介绍，你可以参照一下。

你共启动了多少个服务实例?服务实例启得太多并不是好事.

你可以适当减少部分服务启动实例个数.

另外,当服务很忙的时候,不要让系统自动启动服务的额外实例

(就是每个服务的MAX-MIN值),让他们自动进入队列等待.

你的WSL中的参数 -m,-M,-x设置是多少啊，是不是不够，我看上面的错误是WSH的。

按照理论值：

BEA工程师的经验值。

MAXGTT缺省是100，如果你的并发量不大，可以不改。如果MAXGTT值不够，会在ULOG里有明显的报错。

你的应用是长连接还是短连接，如果是长连接，那你的终端数是400个。你的LICENSES是多少？

WSL中的M和x参数的乘积和你所设的MAXWSCLIENTS保持一致，也和你的LICENSES有对应。MAXWSCLIENTS＝M*x。按照你给的M和x的值乘积是250，和你的MAXWSCLIENTS对照一下。

另外你的MAXSERVICES的值是不是可以适当增大一点。

MAXACCESSERS再加大一点也没太大关系。

如果客户端处理时间长。可以考虑先tpterm，然后等处理完了再来tpfree一些资源，

尽量让交易时间短。

谢谢各位

问题已经解决

问题解决了吗？怎么解决的，说出来让大家学习借鉴一下吗，另外公布一下解决方法也是对那些帮助你的人的一个好的交代吗？

我的ＵＢＢ文件：

--转自搜狗