[Tuxedo] Linux Tuxedo 튜닝 환경설정

 

튜닝을 위해서는 OS / 네트워크 / Tuxedo 환경설정  

3가지가 필요하다.

==

 

자세한 글은 아래 출처에 있으며 Tuxedo 환경설정만 가져왔다.

 

==

 

 

Tuxedo ubbconfig 환경설정

 

 

 

1) WSH의 개수 설정

 

 

 

  WSH의 역할은 WS 클라이언트와 통신하는 역할을 하며, 하나의 WSH은 멀티 플렉싱 기능을 이용하여 하나 이상의 WS 클라이언트와 통신이 가능하다.

 

 

 

  하나의 WSH가 몇 개의 WS 클라이언트와 통신을 할지는 ubbconfig의 WSL 정의 부분에 CLOPT 부분에 "-x" 옵션으로 지정하는데, 일반적으로 10`50개 사이의 값으로 설정하고, 하나의 WSH가 50개 이상의 클라이언트를 처리해야 하는 경우는 WSH의 수를 늘려야 한다.

 

 

 

2) 서버의 갯수의 설정

 

 

 

  Tuxedo 상의 어플리케이션 서버 프로세스의 수는 가능하면 적은 값이 좋습니다. 많은 수의 어플리케이션 프로세스가 기동되게 되면, OS의 자원이 많이 필요할 뿐만 아니라 Bulletin Board에 대한 Lock 경합이 발생하여 성능저하를 유발할 수 있기 때문이다.

 

 

 

  적정 서버수의 선정은 여러 서버를 운영하면서, tmadmin의 pq 옵션 등을 통해서 각 서버 프로세스 내의 Queue에 pending 되는 메시지가 많아지는 것이 원인이 되어 응답속도가 현저하게 떨어질 경우에 그 개수를 늘려주면 된다.

 

 

 

  Tuxedo 서버의 개수는 각 서버의 MIN과 MAX 값으로 설정할 수 있는데, 일반적으로 MIN과 MAX 값은 피크 타임을 기준으로 설정하는게 일반적이다.

 

 

 

3) SYSTEM_ACCESS

 

 

 

  RESOURCES 섹션에 정의되는 값으로 shared memory 영역에 대한 접근 방법을 정의한다. 크게 PROTECTED와 FASTPATH 두 가지로 구분된다.

 

 

 

① FASTPATH로 설정을 해 놓으면 shared memory 영역을 server가 항상 attach 하면서 사용한다. 시스템의 ACCESS 속도는 빠르지만 사용자 어플리케이션에서 잘못된 메모리 영역에 대한 ACCESS를 하거나 core dump나 kill -9와 같은 비 정상 종료시에는 shared memory 영역을 access 하던 중 종료되면 shared memory 영역이 깨져서 비정상적인 작동을 유발하기 때문에 사용자가 개발한 어플리케이션이 안정적일 경우에만 사용하는 것을 권장한다.

 

 

 

② PROTECTED로 설정을 해놓으면 shared memory 영역을 사용할 때만 attach하게 된다. 사용할 때마다 attach와 detach가 발생하기 때문에 속도는 떨어지지만 사용자 어플리케이션이 불안정하여 자주 shared memory 영역을 침범하였을 경우에는 이를 방지하여 안정적인 시스템 운영을 할 수 있도록 해준다.

 

 

 

4) BLOCK TIMEOUT과 TRANSACTION TIMEOUT

 

 

 

  BLOCKTIME은 Tuxedo 클라이언트가 request 보낸 후에 response를 받을 때 까지 시간의 허용값을 정의한다. 만약 이 BlockTIME 보다 시간이 더 소요되면 클라이언트에 이 내용을 알려서 무기한적으로 response를 기다리는 것을 방지한다.

 

 

 

  BLOCKTIME 값의 설정은 SCANUNIT 값에 영향을 받는데, 이 BLOCKTIME에 대한 검사는 SCANUNIT 주기로 발생하기 때문에, 만약 SANITYSCAN이 10초, BLOCKTIME을 60초로 해놓고 서비스를 호출하면 서비스를 호출하는 시점과 SCANUNIT 간격이 다르므로 60초가 아니라 60초 내지 70초 사이에 timeout이 발생한다. transaction timeout도 이와 마찬가지로 tpbegin에 지정한 시간에 정확히 timeout이 발생하는 것이 아니라 SCANUNIT 만큼의 오차가 있을 수 있다.

 

 

 

5) REPLYQ=Y

 

 

 

  각 Service간의 호출이 있고, 호출하는 쪽 (Caller)가 MSSQ를 사용할 때 REPLYQ를 설정해야 한다. 예를 들어 서비스 A에서 서비스 B를 호출할 때, 서비스 B가 호출이 작업이 끝나면 그 내용을 서비스 A의 서버의 request Q로 return한다. 이때 이 서버가 MSSQ를 사용하고 있다면 여러 서버가 이 MSSQ를 공유하고 있기 때문에, Caller 서버가 아닌 전혀 엉뚱한 서버로 갈 수 가 있다.

 

 

 

  이런 상황을 막기 위해서 caller 쪽에 REPLYQ를 따로 지정해서 이런 현상을 방지 하게 된다.

 

 

 

6) MSSQ 사용의 선택

 

 

 

  MSSQ는 Tuxedo에서 여러 개의 어플리케이션의 request Q를 하나로 통합하여 Q의 사용효율성을 높이고 효과적인 부하분산을 하고자 하는데 그 목적이 있으며, 아래와 같은 상황에 따라서 사용 여부를 선택해야 한다.

 

 

 

① MSSQ를 사용할 수 있는 경우

 

   -같은 MSSQ를 사용하는 모든 서버의 서비스가 동일해야 한다.

 

 

 

② MSSQ를 사용하면 좋은 경우

 

   -서버가 2개~12개 사이인 경우

 

   -메시지의 크기가 비슷한 경우

 

 

 

③ MSSQ를 사용하지 말아야 할경우

 

   -하나의 MSSQ를 사용하는 서버가 12개를 넘을 경우에는 MSSQ를 분리하는 것이 좋다.

 

   -메시지가 너무 큰경우

 

   -각각의 서버의 메시지의 크기가 상이하게 다른경우

 

 

 

8) Multithread Option OFF

 

 

 

  각 Tuxedo의 어플리케이션 서버가 Multi Threading을 사용하도록 구현이 되어 있는 경우에, Tuxedo에서는 이 각 Thread간의 동기화를 위해서 Mutex를 사용하는데, 만약 MultiThreading을 사용하지 않는다하더라도 이 Mutex가 Locking을 위해서 사용이되고, 이로 인한 부하를 유발할 수 있다.

 

 

 

  그래서 사용자 어플리케이션에서 Multi Threading을 사용하지 않는다면, 이 Mutex를 사용하지 않도록 설정하여 성능 향상을 기대할 수 있다.

 

 

 

Unix 환경 변수에서 “TMNOTHREADS=Y”로 설정해 주면 된다.

 

 

 

9) Turn off XA transaction

 

 

 

  Tuxedo에서 NON-XA 프로그래밍을 했을 때도 (TMS를 사용하지 않았음에도) Tuxedo에서는 내부적으로 transaction 처리를 위해서 몇가지 기능을 수행을 한다. 그러나 이 NON-XA에서는 사용자가 어플리케이션에서 직접 transaction 관리를 하기 때문에, 이러한 처리는 불필요하고 이로 인해서 불필요한 부하를 유발할 수 있다.

 

 

 

  그래서 NON-XA로 구성된 도메인의 경우 XA transaction 처리를 Turn OFF 할 경우 성능 향상을 기대할 수 있다.

 

 

 

  XA transaction을 Turn off 하기 위해서는 RESOURCES 부분의 OPTIONS에 NO_XA라는 옵션을 추가하면 된다. NO_XA는 XA transaction을 사용하지 않겠다는 의미이기 때문에 TMS를 사용하면 에러를 발생 시키게 된다.

 

 

 

10) Tuxedo Spincount 설정

 

 

 

  Tuxedo는 운영중의 RUNTIME 정보를 BB (Bulletin Board)에 저장해 놓는다. 이 BB는 각 Tuxedo 프로세스간의 공유 메모리 공간이기 때문에, 한 프로세스가 BB를 액세스 하고 있을 때, 다른 프로세스가 BB를 액세스 할 수 없도록 BB에 대한 LOCK을 걸어서 다른 프로세스의 접근을 제어한다.

 

 

 

  이때 BB Lock을 잡고 있는 이외의 프로세스 중에 BB Lock을 잡기 위해 대기 하는 프로세스는 BB Lock이 release 되었는지를 체크하게 되는데, 이 대기 프로세스는 BB Lock이 release 되었는지를 몇 번의 Loop를 돌아서 체크를 한 후에, 만약 Loop내에 Lock이 release가 되지 않으면, 자신의 프로세스 상태를 sleep 상태로 전환한다.

 

 

 

  BB Lock을 잡고 있는 프로세스가 해당 작업을 다 끝내고 Lock을 release할 때, BB Lock을 잡기 위해서 대기중인 프로세스 중에서 sleep 상태인 프로세스가 있으면 notify를 하여 BB Lock이 release가 되었음을 알리고, 다음 프로세스가 BB Lock을 잡고 BB에서 작업을 할 수 있도록 한다.

 

 

 

  위에서 설명한 바와 같이, BB Lock을 얻기 위해서 대기중인 프로세스는 일정주기 만큼 체크를 하다가 그 주기동안 BB Lock을 얻지 못하면 sleep 상태로 빠지는데, 이 sleep과 notify는 OS Level에서 많은 비용을 필요로 하는 작업이다.

 

 

 

  그래서 대기 프로세스가 sleep상태로 가기 전에 BB Lock이 release 되는 것을 체크하는 기간을 길게 줘서 sleep 비율을 줄이는 것이 성능에 유리한데, 이 설정이 MACHINES 섹션의 SPINCOUNT라는 값이다.

 

 

 

  CPU가 1개인 machine에서는 이 SPINCOUNT를 1로 설정하는 것이 성능에 유리하고, 2개 이상의 CPU를 가진 machine에서는 이 SPINCOUNT를 5000~100,000 사이의 값으로 설정하는데, 이 값의 지정은 SPINCOUNT값을 변경 시켜 가면서, Application 성능 테스트를 하고 그 중에서 최적값을 찾아서 선택한다.

 

 

 

예) SPINCOUNT=5000

 

 

 

11) OPENINFO절의 SesWt 설정

 

 

 

  Oracle에 XA를 사용하고 있는 환경에서 application server의 수행 시간 등이 길어져 Transaction time out이 발생한 경우 TMS에 큐잉이 되는 경우에 Oracle의 SesWt를 조정할 필요가 있다.

 

 

 

  SesWt는 다른 session에 의해 사용 중인 transaction branch를 얼마나 기다릴 것인가를 초단위로 지정하기 위한 parameter로 default 값은 60(초)이다.

 

 

 

  application server가 XA를 사용하는 경우 서비스가 시작되면 xa_start()가 수행되고 서비스가 끝나면 xa_end()가 수행된다. 수행 시간이 길어져 Transaction time out이 발생하게 되면 TMS에 의해 xa_rollback() 요청이 있게 되는데, 이때 Oracle은 xa_end()가 수행되지 않은 session에 대해 SesWt에 지정된 시간만큼 xa_rollback()을 wait한다.

 

 

 

  결과적으로 Oracle로부터 xa_rollback()의 return을 받지 못하므로 TMS에 큐잉이 발생한다.

 

 

 

  SesWt은 Oracle에서 xa_open string의 한 field로 제공하는 것으로, ubbconfig의 OPENINFO에서 설정할 수 있다.

 

 

 

12) CLOPT = "-r" 옵션을 이용한 운영 정보의 수집과 분석

 

 

 

이 옵션을 사용하면 각 서버의 서비스 사용 내역이 stderr에 logging된다. 이 내용을 txrpt를 이용해서 분석하면 튜닝에 필요한 정보를 리포트 형식으로 받을 수 있으며, 이 내용을 이용해서 서버의 개수 등과 같은 Tuxedo 운영상 필요한 튜닝을 할 수 있다.

 

 

 

13) 서비스간의 호출

 

 

 

① 같은 Machine내에서는(최소한 같은 GROUP내에서는) Service에서 Service를 호출하는 형태의 Transaction이 발생하지 않도록 Service를 구성하여야 한다. 이를 위해서는 단위 업무 기능을 함수로 구축하고 Service에서 이들 함수를 차례로 호출하도록 한다. 그래서 Service를 마치함수 호출하듯이 사용하는 형태의 프로그램이 나오지 않도록 한다.

 

 

 

② 만일 다른 Machine의 Service를 호출할 필요가 있을 때에는 tpcall()같은 Blocking Call 대신에 tpforward()같은 Non-Blocking Call을 사용하여 Server Process가 필요 없이 대기하고 있는 상황을 방지한다. 다른 Service를 호출하는 Service가 호출의 결과를 필요로 하는 곳에서는 Service를 분할하는 것이 좋다.

 

 

 

Non-Blocking Call을 사용하는 것은 CPU에서 Pipeline을 사용하는 것과 같은 형태의 기법이다. 그래서 Non-Blocking Call을 사용할 때에도 이러한 Pipeline의 효과를 극대화할 수 있는 방법을 사용하여야 할 것이다.

 

 

 

③ Blocking Call이 발생하는 것을 줄이기 위해 Global Transaction의 기동(tpbegin())과 완료(tpcommit())는 반드시 Client에서 호출하도록 한다. Service에서 Global Transaction을 기동하고 완료하는 경우에는완료의 성공메시지가 Service로 반환된후에 Service가 Client로 메시지를 반환하기 전에 장애가 발생하면 Global Transaction은 정상적으로 완료되었지만 Client에서는 이 사실을 알 수 없는 상황이 발생할 수 있다. 그러므로 원칙적으로 Global Transaction의 기동과 완료를 Client에서하여야 한다.

 

 

 

14) 동일 서버 내의 서비스 요청 시

 

 

 

  동일 Application 서버 내의 서비스에 대해 tpcall시에 TPENOENT 에러가 발생한다.

 

 

 

  tpcall시에 TPENOENT에러는 해당 서비스가 없을 때(해당 서버가 shutdown 되었거나, tpcall시 서비스명 기술을 잘못 하였을 때 등) 발생하게 된다.

 

 

 

  그런데 엄연히 해당 서비스가 구동되어 있는 상태인데도 불구하고, 동일 Application 서버 프로세스 내의 한 서비스에서 다른 서비스를 tpcall하는 경우 TPENOENT 에러를 발생시키게 되는데, 그 이유는 deadlock을 방지하기 위함이다.

 

 

 

  Tuxedo Application은 default로 multithread를 사용하지 않도록 생성이 된다(7.1 이후부터 multithread 사용 가능함).

 

 

 

  따라서 위와 같은 요청을 받아주게 되면, tpcall한 서비스는 tpcall 작업에 대한 응답을 받을 때까지 blocking이 될 것이고, 서비스 요청은 해당 서버 프로세스가 이미 tpcall 작업에 걸려있기 때문에 해당 요청을 받아줄 수 없는 상태가 되어 버린다(결국 deadlock을 유발한다.).

 

 

 

  동일 서버이더라도 해당 서버가 여러 개 기동이 되어 있는 경우에는 이와 같은 작업이 가능하다. 이때 tpcall을 하는 프로세스와 tpcall을 받아 서비스를 해주는 프로세스는 서로 다른 프로세스가 된다. 이런 경우 되도록이면 서비스를 다른 서버 프로세스로 분리해 주어야 한다.

 

 

 

 

 

4. Tuxedo 환경 변수

 

 

 

변수	현재  설정값	조치사항	비고
TMULOGUSINGSERVICENAME	Y		WSNAT_CAT:1043 에러가 발생했을 때 클라이언트가 요청한 서비스 이름을 표시하는 방법으로 해당 옵션을 아래와 같이 환경파일에 설정한다. export TMULOGUSINGSERVICENAME=Y
TMNOTHREADS		Y	Tuxedo 7.1부터 Multithreads 환경이 도입됨으로써, 컨텍스트를 보호하기 위해 ATMI 함수를 호출할 때는 내부적으로 항상 Mutexing 함수가 사용된다. 이로 인해 예전에 비해 부하가 증가한다. Multithreads를 사용하지 않는 Application에 대해서는 이를 방치함으로써, 성능을 크게 향상시킬 수 있다. 환경변수 TMNOTHREADS가 선언되어 있으면 Multithreads processing이 방지된다. export TMNOTHREADS=Y 이 기능은 Tuxedo 8.0에서부터 지원되며, 환경변수가 아니라 ENVFILE에 이 변수를 등록하면 프로세스별로 설정을 달리할 수 있다.
TM_KILL_WITH_BBLOCK	Y		Tuxedo 프로세스가 BB에서 작업하고 있을 때 SIGKILL이 내포된 명령어를 사용하여 프로세스를 강제 종료하는 경우에 BB의 데이터가 훼손을 방지할 수 있는 방법으로 해당 옵션을 아래와 같이 환경파일에 설정한다. export TM_KIL_WITH_BBLOCK=Y
SETTCPNODELAY		1	데이터가 소켓에 존재하면 TCP 패킷이 찰 때까지 기다리지 않고 바로 전송하는 방법으로 해당 옵션을 아래와 같이 환경파일에 설정한다. export SETTCPNODELAY=1
BBLRTESCANFIRST		Y	내부 behavior와 관련된 환경변수로  내부 Timeout check시 Transaction table보다 Registry table을 먼저 Check한다. TPETIME에 대한 timing issue를 최소화하기 위해 첫번째만 Registry table를 Check하기 위한 방법으로 해당 옵션을 아래와 같이 환경파일에 설정한다. export BBLRTESCANFIRST=Y
BBWAIT_TIME	1		Tuxedo BBL에 부하가 많이 주어지는 경우, 부하 조절을 위해 Tuxedo 내부적으로 일정시간(초)동안 sleep을 하게 된다. 해당 변수는 BBWAIT_TIME이며 10초로 설정이 되어 있다. 그런데 해당 설정값이 현재로서는 비효율적으로 너무 크게 설정되어 있는 관계로, 외부 환경 변수릍 통해 사용자가 임의로 값을 변경할 수 있게 Enhancement가 이루어 졌다. 해당 환경변수명은 BBWAIT_TIME이며, 사용자가 1~10초사이의 임의의 값을 설정할 수 있다. 현재 설정되어 있는 5초는 순간적인 큐잉이 발생할 경우 너무 큰 시간이므로 순간적인 큐잉이 발생할 경우를 예상하는 최소 설정값인 1초로 설정를 변경해야 한다. Tuxedo BBL에 부하가 많이 주어지는 경우 BBWAIT_TIME의 환경변수와 TM_TKTSPIN_YLDCNT, TM_TKTSPIN_YLDCNT_NAPTIME 환경변수를 같이 설정하는 것이 바람직하다.
TM_TKTSPIN_YLDCNT	1000		Tuxedo BBL의 Spin lock에 대한 반복횟수를 설정한다. (BBWAIT_TIME 설정시 같이 설정해야 함)
TM_TKTSPIN_YLDCNT_NAPTIME	10000		Tuxedo BBL의 Spin lock 에 대한 Sleep time(microsecond)을 설정한다.(BBWAIT_TIME 설정시 같이 설정해야 함)
TM_PREVENT_DEADLOCK		1	내부 Behavior와 관련된 환경변수로 Long time service call을 Issue하기 전에 BB에 대한 Lock을 Release하도록 해당 옵션을 아래와 같이 환경파일에 설정한다. export TM_PREVENT_DEADLOCK=1
TUXWA4ORACLE	1		오라클 데이터베이스와 XA Connection을 맺고 있는 서버의 경우에 해당 데이터베이스로의 접속이 끊어진 경우, 즉 ORA - 3113 에러가 발생하는 경우에 자동으로 재접속을 하기 위해서는 TUXWA4ORACLE 환경 변수가 있어야 한다. "WorkAround For Oracle"이란 의미로 해당 환경 변수에 설정되어 값은 의미가 없고 단지 설정이 되어 있으면 동작한다. 따라서 설정은 아래와 같이 예) export TUXWA4ORACLE = 1 설정을 하면 된다. 재접속은 해당 서버가 오라클에 접근하여 3113 에러가 발생하는 순간에 이루어진다.
ULOGMILLISEC		Y	Tuxedo 9.0부터 ULOG에 time stamp가 1/1000초까지 로깅할 수 있는데, 환경변수 ULOGMILLISEC를 Y로 설정하면 된다. export ULOGMILLISEC=Y

 

 

 

https://mc529.tistory.com/1373

출처 

Linux Tuxedo 튜닝