google_protectAndRun("render_ads.js::google_render_ad", google_handleError, google_render_ad);
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 123456
DOMAINID simpapp
MASTER simple
MAXACCESSERS 100
MAXSERVERS 50
MAXSERVICES 100
MODEL SHM
*MACHINES
MYSERVER LMID=simple
APPDIR="d:tuxdemoconn"
TUXCONFIG="d:tuxdemoconntuxconfig"
TUXDIR="d:tuxedo65"
MAXWSCLIENTS=5
*GROUPS
GROUP1
LMID=simple GRPNO=1
GROUP2
LMID=simple 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 = 4967295 #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 = 10240 #Maximum message size in bytes.
set msgsys:msginfo_msgmnb = 6600000 #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讨论区
»
发起投票
技术讨论
加好友
发消息
2013-1-4 14:34:07 |
赞(
操作
