[Web Server] Tmax CLHQTIMEOUT & tmm 다운 영향도 가이드

본 포스팅은 Tmax Timeout관련 CLHQTIMEOUT와 tmm 다운 영향도 가이드입니다.

---

본 포스팅에서는 TIMEOUT 정책을 결정할 때 CLHQTIMEOUT과 BLOCKTIME 사이에 연관 관계에 대해 가이드 하도록 하겠습니다.

먼저 BLOCKTIME, CLHQTIMEOUT, SVCTIME 의 관계에 대해 알아보겠습니다.

BLOCKTIME,CLHQTIMEOUT,SVCTIME 적용 시간에 따라 다릅니다.

먼저 BLOCKTIME < CLHQTIMEOUT 경우입니다.
BLOCKTIME은 클라이언트가 API 함수를 통해 서비스 요청 후 최대 BLOCKTIME 시간이 지나도록 응답이 없으면 클라이언트 자체적으로 타임아웃 처리하며, 이때 CLH queue에 대기중인 상태라면 CLHQTIMEOUT 까지 대기 후 queue purge 후 해당 메시지는 모두 discarded 됩니다.

다음으로 BLOCKTIME > CLHQTIMEOUT 경우 입니다.
CLHQTIMEOUT이 발생 하면 queue purge 이후 즉시 클이언트에서는 service queue purge 메시를 받게 됩니다.

마지막으로 BLOCKTIME < SVCTIME 경우 입니다.
BLOCKTIME 은 클라이언트가 API 함수를 통해 서비스 요청 후 최대 BLOCKTIME 시간이 지나도록 응답이 없으면 클라이언트 자체적으로 타임아웃 처리하며, 이때 서비스가 수행중인 상태라면 서비스는 계속 처리 되며, 해당 메시지는 모두 discarded 됩니다.  
즉 BLOCKTIME과 상관없이 CLHQTIMEOUT 정의는 가능하나 둘중 적은 시간에 걸려 실제 서비스는 모두 타입아웃에 처리 됩니다.

발생하는 에러와 위치의 차이가 다를뿐입니다.

다음으로 CLHQTIMEOUT 체크 방식에 대해 알아보겠습니다.
CLHQTIMEOUT은 정확하지 않습니다. 주기적으로 체크가 되기 때문에 정확하게 나오지 않습니다.
Tmax 엔진에서 35초 간격으로 체크하면서 Queue 에 적체되어 CLHQTIMEOUT 를 초과한 request를 purge 합니다.

CLHQTIMEOUT 이 설정된 상황에서 queue에서 대기할 수 있는 시간은 CLHQTIMEOUT < queue대기시간 < 35 + CLHQTIMEOUT와 같습니다.

다음으로 CLHQTIMEOUT 발생케이스에 대해 살펴보겠습니다.

먼저 clh큐에 있는 상태에서 CLHQTIMEOUT초과한 경우 발생할 수 있습니다.
다음으로 서버가 요청을 받았을 때, CLHQTIMEOUT이 지난 요청이 Purge 되는 경우에 발생할 수 있습니다.
다음으로 스케줄 Queue에서 꺼내는 시점에서 Purge 되는 경우에 발생할 수 있습니다.
마지막으로 리스케쥴링시 데이터가 QTIMEOUT이 이미 지나 있는 경우에 에러 응답을 줍니다.

CLH0710은 두가지 경우에 발생할 수 있습니다.

먼저 clh 에서 spr로 소켓에 write하는 중 spr이 비정상 종료하였을 경우 다른 spr로 재 스케쥴링하는 중에 clhqtimeout까지 함께 검사하면서 발생할 수 있습니다. clhqtimeout이 아주 짧고 메시지가 비정상적으로 크지 않은 경우에는 발생 가능성은 희박합니다.

두번째로 두개 이상의 clh 가 있는 상황에서 하나의 spr에 동시 스케쥴링 되어 있는 상태에서 spr이 tpreturn(TPEXIT) 와 같은 함수로 종료한 상황이라면 spr에서 수행중이지 않던 요청을 재스케쥴링 하는 중에 clhqtimeout 까지 함께 검사하면서 발생할 수 있습니다.

다음으로 tmm 프로세스를 kill -9로 죽일 경우 Tmax에 끼치는 영향도에 대해 알아보겠습니다.

먼저 shared memory에 대한 영향도 입니다.

tmm 프로세스가 kill -9(SIGKILL)에 의해서 종료되는 경우에는 shared memory를 삭제하지 못합니다.
이 경우에는 4개가 모두 보여야 정상입니다.
signal에 의해 종료될 때 shared memory를 삭제하는 경우는 다음 signal들을 수신한 경우입니다.
SIGTERM, SIGSEGV, SIGBUS, SIGXCPU, SIGXFSZ, SIGKILL에 의해 종료된 것이 정확하다면 아마도 ipcrm 으로 shared memroy를 정리합니다. 이 경우에도 기존의 shared memory에 attach 된 프로세스가 존재한다면 내부적으로 계속 유지되므로 AP가 shared memory에 접근하다가 비정상종료되지 않습니다.

다음으로 TMM connection closed 에러로그를 출력합니다.
libsvr.so 라이브러리에서 tmm 종료시 TMM connection closed[SVR0146]  에러로그를 출력한 이후에 tmm의 fd를 -1로 셋팅하는데, 그 이후에 서비스 요청이 들어올 때 tmm fd의 값이 -1인지 확인하지 않고 사용하고 있어서 비정상 종료되는 현상입니다.

마지막으로 업무 프로세스에서는 다음과 같은 부분에서 문제가 됩니다.

먼저 tmm 프로세스가 죽더라도 AP들의 업무 처리는 CLH가 담당하기 때문에 업무에 영향을 주지는 않습니다.

slog에 기록할 로그들이 기록되지 않습니다. 다만 ulog에는 기록됩니다.
svctimeout 발생시 tpreturn(TPEXIT)의 경우 재기동이 되지 않습니다.
네번째로 ASQCOUNT, POD 기능이 동작하지 않습니다.
다섯번째로 XA를 사용하는 경우 TXLOG를 관리하지 못해서 트랜잭션들이 모두 실패할 가능성이 있습니다.
마지막으로 userlog(), tmadmin() API의 실패 현상이 발생합니다.

그 외에 tmadmin, tmboot, tmdown 등의 utility를 동작할 수 없습니다.

오늘은 여기까지 하겠습니다.

고맙습니다.