TUXEDO运用系统对IPC资源的要求
一个TUXEDO运用系统在运行时会大量用到IPC资源,包括信号灯,消息队列及同享内存,下面对他们的使用情况及与他们有关的操纵系统核心参数分别进行先容:
UBBCONFIG中与IPC资源有关的配置参数
主要有: MAXACCESSERS ,REPLYQ,RQADDR,MAXSERVERS,MAXSERVICE,MAXGTT
TUXEDO运用系统对IPC资源的要求情况
信号灯:
一个进程在要存取TUXEDO运用系统的公告板(BB)之前,它要先取得一个信号灯,所以TUXEDO运用系统所需要的最大信号灯数与MAXACCESSERS的值相等.即:
MAXACCESSERS = No. of semaphores
与信号灯有关的操纵系统核心参数有:
SEMMNS (maximum number of semaphores in use in the system)
SEMMNI (maximum number of active semaphore sets)
SEMMSL (maximum number of semaphores per semaphore set)
SEMMAP (size of control map used to manage semaphore sets)
SEMMNU (number of undo structures in the system)
SEMUME (maximum number of undo entries per undo entries)
消息队列:
TUXEDO运用系统在以下几种情况下会用到操纵系统的消息队列
1. 每一个SERVER都对应一个消息队列,客户真个要求发送到该消息队列中,该SEVER从
该消息队列中取要求并处理.
2. 假如是本地客户端,那末它也对应一个消息队列,用于接收SERVER的处理结果.假如
是远程客户端,那末SERVER的处理结果通过网络传送,不会占用消息队列.
3. 假如采取MSSQ方式,那末在个MSSQ中的所有SERVER共用一个要求队列.
4. 假如某个SERVER或在MSSQ中设置了REPLYQ=Y,那末它要占用一个消息队列
所以一个TUXEDO运用系统需要的最大消息队列为:
Number of Queues = (MAXACCESSERS + Number of Servers with Reply Queues +
Number of MSSQ Sets - Number of Servers in MSSQ Sets)
与消息队列有关的操纵系统核心参数必须满足:
1. 消息队列的个数要足够多,能够满足系统的最大需求
2. 消息的大小必须能满足系统可能出现的最大的消息的大小
3. 消息队列的长度要足够长,能容纳下较多的消息个数,使进对操纵不用等待或不用等太长
的时间
与消息队列有关的操纵系统核心参数有:
MSGMNI (number of unique message queue identifiers)
MSGMAP (size of control map to manage message segments)
MSGMAX (maximum message size)
MSGMNB (maximum message queue length)
MSGSSZ (size of a message segment)
MSGTQL (number of outstanding messages)
MSGSEG (number of message segments in the system)
TUXEDO把全部运用系统的配置信息放到同享内存中,一个TUXEDO运用系统所需要的同享内存由以下参数及配置决定:
1. MAXSERVERS,MAXSERVICE,MAXGTT的值
2. *ROUTING,*GROUP,*NETWORK节的大小
与同享内存有关的操纵核心参数有:
SHMMAX (maximum shared memory segment size)
SHMSEG (maximum number of shared memory segments per process)
SHMMNI (maximum number of shared memory identifiers in the system)
SHMMIN(maximum shared memory segment size) 一般要设为1
一个TUXEDO运用系统在运行时所需要的IPC资源的计算
一个TUXEDO运用系统在运行时所需要的IPC资源可用tmboot -c 计算出来.如UBBCONFIG的内容为:
*RESOURCES
IPCKEY
DOMAINID simpapp
MASTER ***
MAXACCESSERS 100
MAXSERVERS 50
MAXSERVICES 100
MODEL SHM
*MACHINES
MYSERVER LMID=***
APPDIR="d:tuxdemoconn"
TUXCONFIG="d:tuxdemoconntuxconfig"
TUXDIR="d:tuxedo65"
MAXWSCLIENTS=5
*GROUPS
GROUP1
LMID=*** GRPNO=1
GROUP2
LMID=*** GRPNO=11
*SERVERS
DEFAULT:
CLOPT="-A"
call SRVGRP=GROUP1 SRVID=2
conn SRVGRP=GROUP2 SRVID=12 CONV=Y
WSL SRVGRP=GROUP1 SRVID=1116
CLOPT="-A -- -n //XCJ:8888 -m 2 -M 5 -x 6"
*SERVICES
TOUPPER
以上的配置所需要的IPC资源可用tmboot -c计算出,结果以下,可根据计算结果调解操纵系统的核心参数.
D:tuxdemoconn>tmboot -c -y
Ipc sizing (minimum /T values 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
------ ------ ------ ------ ------ ------ ------ ------
XCJ 120 15 115 A + 1 25 50 180K
where 1 <= A <= 8.
The number of expected application clients per processor should
be added to each MSGMNI value.
从输出可知道:
SEMUME,SEMMNU,SEMMNS的值为120,
SEMMSL为15
A*SEMMSL=115,所以A=7,SEMMNI=A+1,所以SEMMNI=8
MSGMNI为25
MSGMAP为50
SHMMAX*SHMSEG必须即是180K
其他核心参数:
在UNIX系统中,对一个用户能具有的系统资源(如最多能启动的进程数,打开的文件数等)是有限制的.主要有以下参数决定:
ULIMIT(maximum file size)
TUXEDO用户所能创建的最大文件,应斟酌创建的SERVER文件的可能大小及ULOG的大小,一个应为ULIMIT.
MAXUP(maximum number of processes per user)
TUXEDO用户所能创建的最大进程数,应设的足够大
IPC资源不够时的出错信息
假如ULOG中出现类似下面的毛病,那末就是操纵系统的核心参数值或操纵系统的资源不够,应进行调解
Clients cannot log into BEA TUXEDO, receive error messages at tpinit:
no space in Bulletin Board
can't register; table full
system init function failed
Global transaction fails, client or server reports failure message
New servers or WSH cannot be started by BEA TUXEDO as needed, error in log file
Message queues become clogged or inaccessible
Write access errors, file system or disk is full
操纵系统核心参数的调解方法
不同操纵系统,核心参数的调解方法都不太一样,一般由系统治理员来进行调解.这里不作先容.在UNIX系统中,只要ROOT用户才能对系统的核心参数进行调解.并且一般要重新启动系统所做的调解才能生效.在调解之前最好对原来的参数做一个备份.
SOLARISE系统核心参数的调解
SOLARISE系统的核心参数保存在文件/etc/system中,可直接对它进行编辑
右侧为添加的说明.
#与同享内存有关的核心参数
set shmsys:shminfo_shmmax = #Maximum shared memory segment size in bytes.
set shmsys:shminfo_shmmin = 1 #
set shmsys:shminfo_shmmni = 100 #
set shmsys:shminfo_shmseg = 10 # Maximum number of shared memory
#segments per process. The maximum amount of
#shared memory in bytes to which a process can
#attach is SHMMAX *SHMSEG.
#与消息队列有关的核心参数
set msgsys:msginfo_msgmni = 600 #Number of unique message queue identifiers.
set msgsys:msginfo_msgmax = #Maximum message size in bytes.
set msgsys:msginfo_msgmnb = #Maximum message queue length in bytes.
set msgsys:msginfo_msgmap = 1200 #(2*msgmni) Number of entries in the control
#map used to manage message segments.
set msgsys:msginfo_msgseg = 1200 #(2*msgmni) Number of message segments in the
#system.
*set msgsys:msginfo_msgtql = 400
#与信号灯有关的核心参数
set semsys:seminfo_semmns = 600 #Maximum number of semaphores in the system.
set semsys:seminfo_semmni = 100 =semmns #Maximum number of active semaphore sets.
set semsys:seminfo_semmsl = 600 =semmns #Maximum number of semaphores per
#semaphore set.
set semsys:seminfo_semmap = 600 =semmni
set semsys:seminfo_semume = 1
set semsys:seminfo_semmnu = 600 >semmns
也能够在SOLARISE的图形化治理界面中进行配置.
HP系统核心参数的调解
1.使用系统活动监视器(SAM-System Activity Momitor)
(1) 运行SAM并选择"内核配置",系统会显示以下四个单元的标识.
子系统
可配置参数
堆集装备
装备驱动程序
(2)选择需要修改的单元:可配置参数
(3)按系统的提示回答题目
(4)系统询问是否是重新引导系统,可回答"是",重新启动系统,使修改生效.
2.手工方式
(1) 实行以下命令进进重建内核的环境
# cd /stand/build
(2) 使用以下的命令对当前的系统配置产生一个系统文件,名为system
s# /usr/lbin/sysadm/system_prep -s system
上面的命令将所有的系统配置信息放到一个文件中,文件名不一定要为system,可
使用任何其他的文件名.
(3) 对system文件进行修改,如修改已存在的参数,增加未列出的参数等.
(4) 使用system文件(假如前面使用其他文件名代替system,那末这里要换为用户定义的文件名),产生conf.c文件,该文件中使用常量对应与内核的可调参数.使用下面的命令实行config程序:
# /usr/sbin/config -s system
(5) 把驱动器对象连接到基本的内核上以重建内核.
# make -f config.mk
(6) 保存旧的系统配置文件
# mv /stand/system /stand/system.prev
(7) 保存旧的内核
# mv /stand/vmunix /stand/vmunix.prev
(8) 将新的系统配置文件移到相应的目录下
# mv ./system /stand/system
(9) 将新的内核移到相应的目录下
# mv /vmunix_test ./stand/vmunix
(10) 重新引导系统并装如新的系统
# shutdown -r -y 60
AIX系统核心参数的调解
在AIX系统中,一般不能对与IPC资源有关的参数进行修改,它们是自适应的.但可对一个用户能打开的最多进程数等其他参数进行修改.可以用SMIT工具进行修改.
TUXEDO运用系统的性能优化方法
一,如何肯定一个TUXEDO运用系统的性能瓶颈
一 个TUXEDO运用系统的整体性能经常是由很多方面决定的,操纵系统,网络,数据库,和运用系统的设计,程序的编写水平都会影响该TUXEDO运用系统 的性能.当性能不好时,主要表现在对客户段的要求响应很慢.这时候,假如用tmadmin,中的pq命令观察,会发现有较多的要求在排队.这时候就要进行性能 调优,而调优首先要肯定全部系统的性能瓶颈所在.那末如何肯定呢
1, 假如客户端与服务端之间在进行大批量的数据传输.可计算一下它们之间的传输速度,
并与FTP工具的速度相比较,来判定网���的速度是否是正常.看网络是否是性能瓶颈.
2, 假如客户端与服务端之间的数据传输量较少,但是服务端有大量的数据库操纵.则很有
可能数据库是性能的瓶颈,可增加该服务的进程数来进步性能. 假如增加该服务的进
程数以后,没起多大的作用.而且用数据库的性能分析工具视察发现数据库的压力较大.
则数据库是性能的瓶颈,应对数据库的进行性能调优.根据经验,数据库经常是一个应
用系统的性能瓶颈.
3, 对UNIX操纵系统,可用sar,glance(hp)等命令观察.看CPU,IO,内存的利用率是否是正常.
对WIND2000系统,可用任务治理器观察系统的资源使用情况.可根据视察到的结果
做相应的系统调优.
4,采取TUXEDO的性能分析工具txrpt.
txrpt可统计出系统内每一个SERVICE的在某段特定时间内所处理的要求的总数及均匀处
理时间,它的使用方法以下:
(1)在UBBCONFIG中SERVER节做以下设置:即在CLOPT中加 -r.
*SERVERS
DEFAULT:
CLOPT="-A -r"
或clopt = "-A -e /log/wsl.log -r -- -n //32.22.22.22:9999"
说明:假如在DEFAULT的CLOPT中加-r参数是对所有的SERVICE调用都进行统计,
假如只在某个SERVER的CLOPT中加-r参数是对该SERVER中的所有的SERVICE调
用都进行统计.
重编译UBBCONFIG后,并重启动TUXEDO后,以后对SERVICE的调用统计信息会自
动写到标准毛病输出文件中,默许为stderr.
(2)一段时间后,可用txrpt进行性能分析,txrpt的命令格式以下:
txrpt [-t] [-n names] [-d mm/dd] [-s time] [-e time]
参数说明:
-t
对输出进行排序,总计处理要求所花的时间越多的排的越靠前.假如不指��,按总
计被调用的次数越多的排的越靠前.
-n names
只输出指定名称的SERVICE的统计信息,假如有多个,可用,隔开.
-d mm/dd
限定日期,统计指定日期的信息. 缺省为当前日期.
-s time
指定统计开始时间:格式为:hr[:min[:sec]].
-e time
指定统计结束时间:格式为:hr[:min[:sec]].
例子:
txrpt -nTOUPPER -d11/05 -s11:03 -e14:28 the report produced looks like the following.
START AFTER: Thu Oct 05 11:01:00 2001
END BEFORE: Thu Oct 05 14:18:00 2001
SERVICE SUMMARY REPORT
SVCNAME 11a-12n 13p-14p 14p-15p TOTALS
Num/Avg Num/Avg Num/Avg Num/Avg
------ -------- -------- -------- -------
TOUPPER 2/0.25 3/0.25 1/0.96 6/0.37
------- ------- ------- ------- -------
TOTALS 2/0.25 3/0.25 1/0.96 6/0.37
上面的例子说明: 在11月5号的11:03到14:28这段时间内,TOUPPER被调用了6
次,均匀每次的处理时间是0.37秒.
留意:txrpt只能统计一天内的信息,即由-D指定的日期.留意当用txrpt进行性能统计
分析时,ULOGDEBUG环境变量不要设为Y,由于它的输出信息会对txrpt造成干扰.
二,进步TUXEDO系统的性能的方法:
(1) 同一个SERVER启动多个进程,假如原来某个SERVER所启动的进程数较少,可增
加它的进程数,并建议使MIN=MAX,使TUXEDO不用进行进程数的动态治理.
假如这些SERVER可配置成MSSQ方式,则应采取MSSQ方式.以下所示:
"simpserv" SRVGRP="GROUP4" SRVID=3 MIN=3 MAX=10
RQADDR="simpserv" REPLYQ=Y
(2) 采取多服务单队列MSSQ(multiple servers signle queue)
在缺省情况下,TUXEDEO的每一个SERVER对应一个要求队列,该SERVER���该
要求队列中取客户端发来的要求,并把处理的结果通过
该要求队列返回给客户端,TUXEDO的SERVER可以配置成多个SERVER对应一个
要求队列,即MSSQ方式,以进步响应的速度.
在以下情况下建议采取MSSQ:
1,服务对实时性要求很高.
2,某个SERVER需要启动多个进程才能满足需要.
3,服务端与客户端之间传送的数据量比较小.
采取MSSQ应留意以下几点:
1, 客户端与服务端之间传送的数据量比较大,由于数据量很大,会把SERVER的要求
队列空间耗尽,使SERVER没法响应客户真个要求,或把处理的结果通过该要求
队列返回给客户端.
2,不要把包括的SERVICE不一样的SERVER配置成MSSQ.
3,很多的SERVER(比如30个)对应一个MSSQ,这时候应把他们配置成几个MSSQ(如3
个,每一个有10个SERVER)效果会更好.
4,不要以为MIN,MAX的值越大越好,主要取决于数据库的速度.
MSSQ配置的方法以下,留意假如该SERVER中的某个SERVICE调用其他的SERVICE,
并有返回结果,则REPLYQ=Y应加上,在下面的配置中,10个 simpserv共用一个要求队
列,同时其中的某个SERVICE 可能回调用其他的SERVICE,所以 REPLYQ=Y.
"simpserv" SRVGRP="GROUP1" SRVID=2
RQADDR="simpserv" REPLYQ=Y MIN=10 MAX=10
(3)系统内核参数的调解
TUXEDO在运行是会大量用到系统的IPC资源,包括同享内存,信号灯,消息队列.一般
UNIX系统缺省的值都太小,可对它们进行调解.
对由于非正常封闭TUXEDO系统,可能造成TUXEDO系统占用的系统IPC资源没法
开释,可用TUXEDO提供的工具ipclean进行回收.
(4)公道处理SERICE与SERVER的关系
假如从治理保护方面看,一个SERVICE对应一个SERVER是最简单的方式.但这会增
加SERVER的数目,使TUXEDO系统对系统的IPC资源要求增大(使系统的性能下降),
或超过(使TUXEDO系统没法启动成功).所以需要把多个SERVICE放到一个SERVER
中.以下降TUXEDO对系统IPC资源的需求.下面是一些把SERVICE放在一起的原
则:
1. 有相互调用的SERICE不要放到同一个SERVER中,以免引发死锁现象.
2. 实行时间相近的SERVICE可放到同一个SERVER中.
3. 同一个SERVER中的SERVICE最好有相同的服务优先级,假如不同,最低的那个
的要求可能要很长时间才得到处理.
4. 一个SERVER中不要有太多的SERVICE.
5. 把多资源要求相近的SERVICE放到同一个SERVER中.
6. 可根据业务规则把SERVICE放到同一个SERVER中.
7. 对一些使用率较高的(如:银行的取款对应的SERVICE)应单独放在一个SERVER中,
并采取MSSQ方式.不要把它们与其他的SERVICE放在同一个SERVER中.
(5)TUXEDO可对服务设置优先级(0-100),对照较重要的SERVEICE,可进步它的服务
优先级,使它较快得到响应,以下面的例子,在一个银行系统中,挂失服务
(LOSTCARD)的优先级比取款服务(WITHDRAWAL)高,可以使它较快得到处理.
*SERVICES
WITHDRAWAL PRIO=50
LOSTCARD PRIO=80
(6)MAXWSCLIENTS的设置
MAXWSCLIENTS设置最多答应多少个远程客户端数同时连接到该TUXEDO系统
上,与所购买的LICNESE数有关,可设置的比所购买的LICENSE数大一些.当并
发连接数大于所购买的LICENSE数时,TUXEDO会报警,(在ULOG中回有信息)
当超过10%时,TUXEDO谢尽新的CLIENT端连进.TPINIT()会报错.
(7) WSL的配置,WSL进��用于监听远程客户真个连接,它的以下几个选项会影响性能.
-m: 最小启动WSH的进程数,缺省为0.可直接设的和-M项的值一样.
-M:最小启动WSH的进程数,缺省为MAXWSCLIENTS /x.
-x:每一个WSH进程可处理的远程客户端数,缺省为10.
-c:当客户端与服务端之间传输的数据量(单位为:字节)大与-c指定的值时,自动进行
数据紧缩,假如网络状态不好,该选项应加上.
WSL SRVGRP=GROUP1 SRVID=112
CLOPT="-A -- -n //SERVER:8008 -m 10 -M 10 -x 10 -c 1024"
(8)对采取会话通行方式的SERVER,可多划分几个组,也能进步性能.
"simpserv" SRVGRP="GROUP2" SRVID=2
RQADDR="simpserv1" REPLYQ=Y MIN=10 MAX=10 CONV=Y
"simpserv" SRVGRP="GROUP3" SRVID=2
RQADDR="simpserv2" REPLYQ=Y MIN=10 MAX=10 CONV=Y
"simpserv" SRVGRP="GROUP4" SRVID=2
RQADDR="simpserv3" REPLYQ=Y MIN=10 MAX=10 CONV=Y
上面的配置的性能比下面的配置要好,固然组的个数也不是越多越好.
"simpserv" SRVGRP="GROUP2" SRVID=2
RQADDR="simpserv3" REPLYQ=Y MIN=30 MAX=30 CONV=Y
(9) 假如只有一个数据库,就没必要用XA,TUXEDO 与数据库之间的连接应当尽量在TUXEDO SERVER 的 tpsvrinit()中创建,在tpdone()中断开.
(10)选用正确的通讯方式,例如当进行大量的数据传输时,采取会话通讯方式的性能
就比采取同步调用方式好.
(11)最好把TLOG和QUEUS SPACE创建在磁盘裸装备上,
(11) 把QUEUE SPACE创建在内存上比创建在磁盘上的性能要好很多
(12) 假如一个SERVER要起很多进程,如60个,最好是分成几个组
findmisc SRVGRP=GROUP242 SRVID=700 MIN=10 MAX=10
REPLYQ=Y RQADDR="findmisc1"
findmisc SRVGRP=GROUP242 SRVID=700 MIN=10 MAX=10
REPLYQ=Y RQADDR="findmisc2"
findmisc SRVGRP=GROUP242 SRVID=700 MIN=10 MAX=10
REPLYQ=Y RQADDR="findmisc3"
三,其他方面:
1, ULOG文件假如很大,也会影响性能,在一个生产系统中,应把没必要要的日志信息
往掉,不要往ULOG文件写太多的信息.
2, 尽量不在客户端要开始一个事务.由于客户真个用户可能开始一个事务,然后不往
下处理,白白占用数据库资源.同时与在服务端开始 一个事务相比,在客户端开始
一个事务还有很多其它的缺点.
3, 一个TUXEDO系统可以支持的最大并发连接数是由所购买的LICENSE数决定的.
它对系统的性能起决定性的作用.
4,TUXEDO的客户端通过tpinit()函数与服务端建立连接,假如客户端对服务真个调
用很频繁,如电信的前台收费业务,银行的存取款业务可在客户端启动上就建立一
个常连接,到客户端封闭时才用tpterm()断开,对一些调用很少的业务,可在真正
要调用服务之前才与服务端建立连接,调用结束后,马上把连接断开.假如所购买
的LICENSE数较少,最好所有的调用都采取第二种方式.
总之,系统性能的调优是个很复杂的进程,要权衡各个方面的因素,并要靠很多的经验积累.
当前位置：
论坛首页 »
自由讨论区 »
MQ, Tuxedo及OLTP讨论区
»
发起投票
技术讨论
加好友
发消息
2012-7-6 14:17:55 |
赞(
操作
