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数较少,最好所有的调用都采用第二种方式.
总之,系统性能的调优是个很复杂的过程,要权衡各个方面的因素,并要靠很多的经验积累.