장점 : - 서버 프로세스당 Memory는 서비스가 많건 적건 일정
- 프로세스의 수가 적을수록 성능에 영향
1. Grouping 기준
q 한 서버 프로세스내에서 tpcall() 사용 금지
-> 서비스 형태 대신 “C 함수” 호출은 사용 가능
q 비슷한 Response Time을 갖는 서비스들은 Grouping
· 1초 이내는 Grouping하고
· 5초 이상은 분리
q 시간이 오래 걸리는 서비스와 Batch성 작업을 하는 서비스는 분리
q DB 변경 서비스와 조회 서비스는 분리
· XA를 사용할 경우, 미사용시 보다 10 ~ 25% Overhead 발생
· 조회성 업무는 NON-XA 사용이 바람직 함 !
q TUXEDO 구성화일의 *GROUP 섹션에서 Group이 분리되는 서비스는 분리
· DB를 Access하는 서비스와 Access 하지않는 서비스는 분리
· ORACLE의 경우 DB User가 다른 경우에는 서비스를 분리
· 동일한 RM (DBMS)을 접근하는 서비스끼리는 Grouping
q 매우 자주 Call하는 서비스는 분리
“$ txrpt < stderr” 수행결과에서
· 평균수행시간이 1초 이상되면 SQL문장 Tuning
· 발생건수 * 평균수행시간 >= 1800 이면 매우 자주 Call하는 서비스
2. 사전작업과 그에따른 분석
q 서비스와 서버 프로세스의 수행빈도를 Check.
전체 업무를 단계별로 나누어 최소 업무단위까지 전개한다.
최소 업무단위 즉, 서비스들이 하는 작업과 예상 빈도수를 Check한다.
관련된 업무와 빈도수를 기준으로 빈번하다고 생각되는 서비스들은 3~4개 정도를
하나의 서버 프로세스로 묶고 나머지 것들은 10~20개 정도를 하나로 묶는다.
· 3~4개의 서비스를 하나의 서버 프로세스로 묶고 몇개의 프로세스로 복제.
-> 이 서버 프로세스들은 빠른 응답시간, 부하조절을 위하여 MSSQ를 사용
· 빈도수에 따라 하나의 서비스를 하나의 서버 프로세스로 생성
일정 시간을 두고 많은 클라이언트를 접속시켜 각각의 서비스들을 수행시켜 본다.
Test 후의 분석은 다음의 요령을 따른다.
· “tmadmin”의 “psr” 명령 수행결과
a.out Name Queue Name Grp Name ID RqDone Load Done Current Service
---------- ---------- -------- -- ------ --------- ---------------
BBL 214578 SITE1 0 8 400 ( IDLE )
TMS_ORACLE7 EMP1_TMS EMP1 30001 0 0 ( IDLE )
TMS_ORACLE7 EMP1_TMS EMP1 30002 3 150 ( IDLE )
WSL 00101.00020 WSGRP 20 0 0 ( IDLE )
empmul 00001.00021 EMP1 21 3 150 ( IDLE )
- 여기서 “RqDone”은 서버 프로세스가 수행된 횟수를 나타내는 것으로,
1시간동안의 수행횟수가 7200번 이상이 되는 것은 빈번하다고 판단되므로
이경우에는 서버 프로세스를 재구성하거나 여러개를 Booting시켜야 함.
· 서버 프로세스를 재구성을 할 경우는 “txrpt”의 수행결과 Check.
SVCNAME 11a-12n TOTALS
Num/Avg Num/Avg
--------------- -------- -------
SEL 9/0.09 9/0.09
--------------- ------- -------
TOTALS 9/0.09 9/0.09
- 이 화면은 11시에서 12시 사이에 “SEL”이라는 tjqltm가 9번 수행되었고 평균 수행
시간이 0.09 라는 것을 나타낸다.
- 여기서, 발생건수 * 평균수행시간 >= 1800 이면 매우 자주 Call하는 서비스
q 수행시간이 오래 걸리는 것과 그렇지 않은 것을 Check.
첫번째로 하여야 할 작업은 각 서비스의 수행 시간을 “txrpt”로 Check.
평균 수행시간이 1초가 넘는 서비스들은 일단 오래 걸리는 것으로 간주하고 각
서비스의 Source에서 SQL문장만을 떼어내어 이것의 시간을 Check해 본다.
이것으로도 비슷한 시간이 나온다면 SQL문장을 Tuning을 해보고, 아니라면
Logic상에서 시간 단축 방법을 생각해 본다.
실제로 시간이 오래 걸릴 수 밖에 없는 서비스도 있을 수 있으므로 이런 것들은 다른
On-Line 작업에 방해가 되지 않도록 분리한다.
q WSL 서버의 CLOPT Parameter 조정
PC를 켜면 Default로 TUXEDO에 접속하도록 되어 있다면 중간중간 WSH가 기동되는
부하를 줄이기 위해 WSH의 Minimum을 Client 수에 맞춘다 ( “- m” Option ).
그렇지 않다면 실제 Client수의 50 % 정도로 맞춘다.
하나의 Call을 발생시킨 후 다음 Call이 발생되는 것이 짧다면 “-x” Option을 10 정도로
하고, 그렇지 않다면 20 정도로 한다.
Call 다음에 Call이 발생될 최장시간 (접속후 TUXEDO 서비스를 사용하지 않을 시간)
을 잡아 “-T” Option으로 접속에 대한 Time-out을 준다.
'▶ Tuxedo > 기술자료' 카테고리의 다른 글
| TUXEDO MP Mode Migration 사용방법 (0) | 2012.03.16 |
|---|---|
| TUXEDO Multithreading 과 Multicontexting 프로그래밍 사용방법 (0) | 2012.03.16 |
| PENTRY 에러 발생시 (0) | 2012.02.29 |
| P-Project 관련 조합 H/W 선정을 위한 BMT에서 발생한 문제 (0) | 2012.02.29 |
| 모 Site에서 발생한 문제 (0) | 2012.02.29 |