轉於brucelee0224 的 http://blog.csdn.net/brucelee0224/article/details/6069751
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:/tuxdemo/conn"
TUXCONFIG="d:/tuxdemo/conn/tuxconfig"
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:/tuxdemo/conn>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數較少,最好所有的調用都採用第二種方式.
總之,系統性能的調優是個很複雜的過程,要權衡各個方面的因素,並要靠很多的經驗積累.