주식회사 누리아이티

정보자산의 보안강화를 위한 2차인증 보안SW 및 지문인식 OTP/출입/보안카드 전문기업

▶ Tuxedo/기술자료

Tuxedo 서비스를 서버 프로세스로 Grouping하는 방안

누리아이티 2012. 2. 29. 14:56

장점 : - 서버 프로세스당 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 준다.