9. 도서관/__사. Network

Tuxedo 서버 Hang(정지)

행복 금융 2008. 11. 16.

문제 해결 가이드
지원 진단 패턴

Tuxedo 서버 Hang(정지)

문제 설명
Tuxedo 응용 프로그램에서 Tuxedo의 프로세스가 현재 작업을 완료하지 못하고 새 요청에 응답하지 않습니다. 일반적으로 이런 프로세스도 적은 CPU 사용량을 소모합니다. CPU 사용량이 높은 경우 이 문제에 대한 해결 방법을 제공할 예정인 높은 CPU 사용량 패턴을 참조하십시오. 링크는 발표되는 대로 제공될 것입니다.

Tuxedo 서버 측에 Hang(정지)될 수 있는 두 가지 유형의 프로세스가 있습니다. Tuxedo 관리 프로세스(예: DBBL, BBL, BRIDGE, GWTDOMAIN, GWADM, TMS 등)와 응용 프로그램 프로세스입니다. 이 설명서에는 응용 프로그램 프로세스의 Hang(정지)에 대해 주로 설명합니다.

문제 해결
다음 항목을 모두 수행해야 하는 것은 아닙니다. 어떤 경우에는 다음 중 일부만 수행하여도 해결할 수 있습니다.

항목 바로가기

페이지 맨 위

문제 발생 원인
일반적으로 일부 리소스가 부족하여 서버가 Hang(정지)됩니다. 리소스가 부족하거나 리소스에 mutex lock이 있으면 프로세스가 필요한 리소스를 얻을 수 없기 때문에 새 요청을 서비스할 수 없습니다. 예를 들어, 공유 메모리를 사용하려는 프로세스는 다른 프로세스가 semaphore를 들어 올려 lock을 해제할 때까지 대기합니다. 다른 프로세스가 lock을 해제하지 않으면 대기 중인 프로세스가 Hang(정지)됩니다.

가능한 이유

데드락(Deadlock)

리소스 차단

Sleep 루프

시간 초과

높은 CPU 사용량--높은 CPU 사용량 지원 패턴을 참조하십시오.

페이지 맨 위

문제 조사
문제 조사의 목적은 Hang(정지)된 서버의 스택 정보를 검색하고 분석하여 서버 Hang(정지) 원인을 찾는 것입니다.

서버 Hang(정지) 여부를 찾는 방법 문제 조사 단계는 다음과 같습니다.

Tuxedo 관리 도구 "tmadmin"을 사용합니다.
"pq" 명령으로 tuxedo 큐에 들어 있는 요청을 검사합니다.
"psr" 명령으로 tuxedo 서버의 상태를 검사합니다.
운영 체제별 유틸리티를 사용하여 운영 체제에 있는 현재 tuxedo 서버의 CPU 사용량을 검사합니다.
truss, strace, gdb, dbx 등과 같은 운영 체제의 디버깅 도구를 사용하여 서버가 Hang(정지)된 시스템 호출 또는 API 세부 사항을 찾습니다.

또는 "kill" 시그널 "SIGABRT"를 해당 프로세스에 대해 실행하여 Hang(정지)된 서버의 코어 덤프를 생성합니다. 디버그 도구로 코어 파일을 디버깅하여 Hang(정지)된 프로세스를 찾을 수 있습니다. 이 문제에 대한 해결 방법은 앞으로 발표될 코어 덤프 패턴을 참조하십시오. 링크는 발표되는 대로 제공될 것입니다.

서버 Hang(정지)에 대한 데이터를 수집하려면 운영 체제별로 아래 단계를 따르십시오.

페이지 맨 위

Solaris
"tmadmin"을 실행하여 서버 상태를 검사합니다.

"pq"를 사용하여 요청 큐에 들어 있는 요청 정보를 수집합니다. 예를 들어 다음과 같습니다.

echo pq | tmadmin

데이터를 수집하는 데 다음 셸 스크립트를 사용할 수 있습니다.

pq.sh t [n](t초 n 간격으로 결과 출력)

페이지 맨 위

#!/usr/bin/sh
if test -z "$1"
then
sleep_time=0
else
sleep_time=$1
fi

if test -z "$2"
then
    loopnum=1
else
    loopnum=$2
fi
num=0
while [ $num -lt $loopnum ]
do
    num=`echo "$num + 1" | bc`
    echo pq | tmadmin 2>/dev/null
    sleep $sleep_time
done

출력은 다음과 유사합니다.

$ pq.sh 5 3 > Prog Name  Queue Name   # Serve Wk Queued   # Queued Ave. Len Machine
--------- ------------------- --------- -------- -------- -------
simpserv   00001.00100   1 100  2    0.0   simple
BBL           222222            1   0    0    0.0   simple
>

> Prog Name  Queue Name   # Serve Wk Queued   # Queued Ave. Len Machine
--------- ------------------- --------- -------- -------- -------
simpserv   00001.00100   1 250   5 0.0   simple
BBL           222222            1   0    0    0.0   simple
>

> Prog Name  Queue Name   # Serve Wk Queued   # Queued Ave. Len Machine
--------- ------------------- --------- -------- -------- -------
simpserv    00001.00100   1 400   8 0.0   simple
BBL            222222            1   0    0    0.0   simple
>

"#Queued" 열의 값을 살펴보면 일부 서버는 긴 시간 동안 증가만 하고 감소하지 않습니다. 이 서버의 큐 이름을 기록해 둡니다.

앞의 예제에서 문제의 서버는 simpserv이고 큐 이름은 00001.00100입니다.

"psr"을 사용하여 서버 상태를 검사합니다.

echo psr -q queue_name | tmadmin 2>/dev/null | grep process_name

$ echo psr -q 00001.00100 | tmadmin 2>/dev/null | grep simpserv

simpserv 00001.00100 GROUP1 100 0 0 TOUPPER

그러면 클라이언트 요청을 처리 중인 서버가 표시됩니다. 네 번째 열은 서버의 SRV_ID입니다.

이 예제에서 simpserv는 "TOUPPER" 서비스를 처리 중이고 SRV_ID는 100입니다.

"tmadmin"을 실행시키고 자세한 출력(verbose)을 설정하고 SRV_ID를 사용하여 서버를 조사합니다.

$ tmadmin

Distributed under license by BEA Systems, Inc.

Tuxedo is a registered trademark.

> verbose

Verbose now on.

> psr -i 100

Group ID: GROUP1, Server ID: 100

Machine ID: simple

Process ID: 16979 , Request Qaddr: 905, Reply Qaddr: 905

Server Type: USER

Prog Name: /home/yhuang/apps/simpapp/simpserv

Queue Name: 00001.00100

Options: ( none )

Generation: 1, Max message type: 1073741824

Creation time: Fri Sep 24 00:44:42 2004

Up time: 0:06:26

Requests done: 0

Load done: 0

Current Service: TOUPPER

문제의 tuxedo 서버에 대한 프로세스 ID를 얻을 수 있습니다. 프로세스 ID(PID)는 16979입니다.

ps 명령을 실행하여 Tuxedo 서버의 PID를 확인합니다.

$ ps -ef | grep simpserv

yhuang 16979 1 0 22:56:28 pts/10 0:00 simpserv -C dom=simpapp -g 1 -i 1 -u slsol3 -U /home/yhuang/apps/simpapp/ULOG -

prstat를 실행하여 이 프로세스의 CPU 사용량을 조사합니다.

prstat -L -p <PID> 1 1

$ prstat -L -p 16979 1 1

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID

16134 yhuang 6256K 3520K sleep 59 0 0:00.00 0.0% simpserv/5

16134 yhuang 6256K 3520K sleep 58 0 0:00.00 0.0% simpserv/4

16134 yhuang 6256K 3520K sleep 45 0 0:00.00 0.0% simpserv/3

16134 yhuang 6256K 3520K sleep 56 0 0:00.00 0.0% simpserv/2

16134 yhuang 6256K 3520K sleep 58 0 0:00.00 0.0% simpserv/1

pstack 명령을 실행하여 스레드 스택 정보를 검사합니다.

pstack 명령은 특정 프로세스의 스레드 스택 정보를 표시할 수 있습니다. 스택에 들어 있는 "main" 함수는 런타임 시스템 호출의 시작입니다. 스택을 사용하여 tuxedo 서버가 Hang(정지)된 시스템 호출이나 API를 식별할 수 있습니다.

예를 들어, 다음 스택 정보에서 서버 Hang(정지)이 "sleep" 시스템 호출에서 발생할 것을 알 수 있습니다.

$ pstack 16979

16979: simpserv -C dom=simpapp -g 1 -i 1 -u slsol3 -U /home/yhuang/apps/simpa

----------------- lwp# 1 / thread# 1 --------------------

fef1f004 lwp_sema_wait (20fe0)

fee39ac4 _park (20fe0, fee5e000, 0, 20f20, 24d84, 0) + 114

fee3978c _swtch (20f20, 0, fee5e000, 5, 1000, 0) + 424

fee37e10 cond_reltimedwait (0, 0, 0, 1, 0, 0) + 1f8

fee496c4 sleep (0, fe28c6e8, 44340, ff3e7fe8, fee5e000, fef273d0) + 17c

00010a78 TOUPPER (2d20c, ffbef7ec, ffbef7ee, 3, 0, 5) + 68

ff24f8f0 _tmsvcdsp (215c8, ffbef8d4, 0, c0000000, 80000, 1) + e58

ff272454 _tmrunserver (2bd20, ff129430, 0, 0, 27d70, 22c10) + 1064

ff24e668 _tmstartserver (e, ffbefa04, 20ce8, fee9bbd0, 31ea0, 0) + 1b0

00010990 main (e, ffbefa04, ffbefa40, 20c00, 0, 0) + 20

000108f8 _start (0, 0, 0, 0, 0, 0) + 108

페이지 맨 위

Linux

tmadmin 명령을 실행하여 서버 상태를 검사합니다. Solaris 운영 체제에서도 이 명령은 동일합니다.

ps 명령을 실행하여 서버 상태를 검사합니다.

ps -e -o pid,user,sz,pcpu,state,args | grep <process_name> 또는 <PID>

$ ps -e -o pid,user,sz,pcpu,state,args | grep simpserv

PID USER SZ %CPU S COMMAND

17553 bea 1098 0.0 S simpserv -C dom=site1 -g 2 -i 100 -u dell40 -U /usr/

4열의 "%CPU"는 서버의 CPU 사용량을 나타냅니다.

5열에서 "S"는 프로세스 상태를 나타냅니다. 자세한 의미는 다음과 같습니다.

D 인터럽트 불가능한 휴식 상태(일반적으로 IO)(Uninterruptible Sleep)(usually IO))

R 실행 가능(큐에 대해 실행)(Runnable(on run queue))

S 휴식 상태(Sleeping)

T 추적됨 또는 중지됨(Traced or Stopped)

Z 작동 중지된("좀비") 프로세스(Defunct ("zombie") process)

top 명령을 실행하여 서버 프로세스의 CPU 사용량을 표시합니다.

top -p <PID> -n 20

$ top -p 17553 -n 10

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND

17553 qimz 15 0 2116 2116 1504 S 0.0 0.0 0:00 simpserv

gdb 명령을 실행하여 프로세스 스택 정보를 표시합니다.

gdb <prog_path> <PID>

prog_path: 실행 파일 경로

$ gdb simpserv 17553

(gdb) where

#0 0x402b8cb1 in nanosleep () from /lib/libc.so.6

#1 0x402b8b31 in sleep () from /lib/libc.so.6

#2 0x08048971 in TOUPPER (rqst=0x0) at simpserv.c:41

#3 0x40074775 in _tmrunserver () from /usr/tuxedo/tuxedo8.0/lib/libtux.so

#4 0x400574f5 in _tmstartserver () from /usr/tuxedo/tuxedo8.0/lib/libtux.so

#5 0x0804892a in main ()

#6 0x40219727 in __libc_start_main () from /lib/libc.so.6

(gdb) detach

(gdb) quit

strace 명령을 실행하여 시스템 호출을 조사할 수 있습니다.

예: strace -o outfile -p <PID>

$ strace -o strace.out -p 17553

$ cat strace.out

rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0

rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0

rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0

nanosleep({1000, 0}, <unfinished ...>

페이지 맨 위

AIX

tmadmin 명령을 실행하여 서버 상태를 검사합니다. Solaris 운영 체제에서도 이 명령은 동일합니다.

ps 명령을 실행하여 프로세스 ID와 프로세스의 CPU 사용량을 표시합니다.

ps -auxwww | grep process_name

$ ps aux | head -n 1; ps aux | grep simpserv

USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND

qimz 3908 0.0 0.0 904 1036 pts/2 A 17:15:26 0:00 simpserv -C dom=A

dbx 명령을 실행하여 프로세스 스택 정보를 표시합니다.

dbx 명령을 실행하여 Hang(정지) 서버를 검사합니다. dbx를 입력한 후 where을 입력하여 스택 정보를 인쇄할 위치를 지정합니다. dbx에서 종료하기 전에 detach를 입력하여 프로세스를 분리하고 dbx를 종료합니다. AIX5L만 truss 도구를 제공합니다.

dbx -a <PID>

$ dbx -a 3908

stopped in _p_nsleep at 0xd0013b34 ($t1)

0xd0013b34 (_p_nsleep+0x10) 80410014 lwz r2,0x14(r1)

(dbx) where

_p_nsleep(??, ??) at 0xd0013b34

raise.nsleep(??, ??) at 0xd018560c

sleep(??) at 0xd01e0250

TOUPPER(0x2002a38c), line 45 in "simpserv.c"

_tmsvcdsp() at 0xd3741b48

_tmrunserver() at 0xd36f30c4

_tmstartserver() at 0xd37a5e94

main(0x12, 0x2ff227bc) at 0x100003f0

(dbx)deatch

페이지 맨 위

HP-UX

tmadmin 명령을 실행하여 서버 상태를 검사합니다. Solaris 운영 체제에서도 이 명령은 동일합니다.

ps 명령을 실행하여 서버의 PID(프로세스 ID)를 표시합니다.

ps -ef | grep <process_name>

다음은 예제 출력입니다.

$ ps -ef | gep simpserv

bea 17054 1 0 15:31:24 ? 0:00 simpserv -C dom=tux_ora -g 2 -i 100 -u bea-cs -U /home/qimz/

출력의 두 번째 열은 PID로, 값은 17054입니다.

ps 명령을 실행하여 서버 프로세스의 상태를 조사합니다.

환경 변수 설정: export UNIX95=XPG4

예: ps -e -o pid,user,sz,pcpu,state,args | grep <process_name> 또는 <PID>

$ ps -e -o pid,user,sz,pcpu,state,args | grep 17054

PID USER SZ %CPU S COMMAND

17054 bea 73 0.02 S simpserv -C dom=tux_ora -g 2 -i 100 -u bea-cs -U /home/qimz/

4열의 "%CPU"는 서버의 CPU 사용량을 나타냅니다.

5열에서 "S"는 프로세스 상태를 나타냅니다. 자세한 의미는 다음과 같습니다.

0 존재 안 함(Nonexistent)

S 휴식 상태(Sleeping)

W 대기 중(Waiting)

R 실행 중(Running)

I 중간(Intermediate)

Z 종료됨(Terminated)

T 중지됨(Stopped)

X 증가 중(Growing)

tusc 명령을 실행하여 프로세스의 시스템 호출을 조사합니다.

HP UNIX의 "tusc" 도구는 다음 링크에서 다운로드할 수 있습니다.

http://www.hp.com/workstations/segments/mcad/dassault/plmcc/perf_tools.html

tusc 도구를 사용하여 프로세스의 모든 시스템 호출 정보를 표시할 수 있습니다. HP UNIX의 tusc 패키지에는 "truss" 도구도 포함되어 있습니다. 명령줄 형식은 다음과 같습니다.

truss -d -o <outfile> -p <pid>

"-d" 매개변수는 타임스탬프와 함께 모든 시스템 호출을 표시합니다.

다음 truss 출력을 살펴보면 다음을 알 수 있습니다.

즉, 서버 프로세스가 API sigtimedwait에서 처음 차단되고, 1초 후 이 시스템 호출이 시그널에 의해 인터럽트되고(EAGAIN으로 반환), "time" 시스템 함수로 현재 시간을 구하고, sigtimedwait 함수에 대한 호출이 다음 루프를 시작합니다. 프로세스가 "sleep" 함수의 루프에서 Hang(정지) 중인 것을 알 수 있습니다.

$ truss -o 17054 .out -p 17054

Attached to process 17054 ("simpserv -C dom=tux_ora -g 2 -i 100 -u bea-cs -U /home/qimz/") [32-bit] )

0.0000 sigtimedwait(0x7b040ef0, NULL, 0x7b040f10) [sleeping]

0.8234 sigtimedwait(0x7b040ef0, NULL, 0x7b040f10) ERR#11 EAGAIN

0.8239 time(NULL) = 1032847337

0.8240 time(NULL) = 1032847337

1.8334 sigtimedwait(0x7b040ef0, NULL, 0x7b040f10) ERR#11 EAGAIN

1.8336 time(NULL) = 1032847338

1.8337 time(NULL) = 1032847338

2.8435 sigtimedwait(0x7b040ef0, NULL, 0x7b040f10) ERR#11 EAGAIN

2.8490 time(NULL) = 1032847339

2.8680 time(NULL) = 1032847339

3.8734 sigtimedwait(0x7b040ef0, NULL, 0x7b040f10) ERR#11 EAGAIN

3.8736 time(NULL) = 1032847340

3.8738 time(NULL) = 1032847340

4.8906 sigtimedwait(0x7b040ef0, NULL, 0x7b040f10) ERR#11 EAGAIN

4.8908 time(NULL) = 1032847341

4.8910 time(NULL) = 1032847341

페이지 맨 위

Windows

ipcs 명령을 실행하여 큐에 들어 있는 메시지를 조사합니다.

예: ipcs -qob(출력의 7열 QNUM은 메시지 번호를 표시합니다.)

D:\Projects\testcase\simpapp>ipcs -qob

IPCS status from BEA_segV8.1 as of Sat Sep 25 01:18:18 2004

T ID KEY MODE OWNER GROUP CBYTES QNUM QBYTES

Message Queues:

q 2305 0x0001e242 -Rrw-rw-rw- 0 0 0 0 65536

q 3074 0x00000000 --rw-rw-rw- 0 0 292 1 65536

q 3843 0x00000000 -Rrw-rw-rw- 0 0 292 1 65536

q 5636 0x00000000 --rw-rw-rw- 0 0 292 1 65536

q 2309 0x00000000 -Rrw-rw-rw- 0 0 292 1 6553

QNUM에 대해 증가하기만 하는 메시지 큐 ID를 찾습니다.

tmadmin 명령을 실행하여 메시지 큐 ID에 대한 서버를 조사합니다.

tmadmin < psr.txt

psr.txt에는 다음 두 줄이 포함됩니다.

verbose

psr

verbose가 켜져 있으면 psr 명령은 프로세스 ID와 함께 tuxedo 서버에 대한 자세한 정보를 표시합니다.

D:\Projects\testcase\simpapp> tmadmin < psr.txt | findstr 3843

Process ID: 2008 , Request Qaddr: 3074, Reply Qaddr: 3843

PID는 2008입니다.

prstat 명령을 실행하여 PID와 서버의 CPU 사용량을 표시합니다.
Windows에서 pslist 도구를 사용하여 Hang(정지)된 프로세스의 "CPU 시간"을 표시할 수 있습니다. "pslist" 명령 도구는 http://www.sysinternals.com/ntw2k/freeware/pslist.shtml에서 다운로드할 수 있습니다.

예: pslist <PID> 또는 <process name>

>pslist 2008

Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time

simpserv 2008 8 1 128 780 0:00:00.040 0:38:55.348

strace 명령을 실행하여 프로세스 스택 정보를 조사합니다.

"strace" 명령은 http://www.sysinternals.com/ntw2k/freeware/pslist.shtml에서 다운로드할 수 있습니다.

strace -p <PID>

>strace -p 2008

1 356 324 NtDelayExecution (0, {-100000000, -1}, ... ) == 0x0

2 356 324 NtDelayExecution (0, {-100000000, -1}, ... ) == 0x0

3 356 324 NtDelayExecution (0, {-100000000, -1}, ... ) == 0x0

4 356 324 NtDelayExecution (0, {-100000000, -1}, ... ) == 0x0

5 356 324 NtDelayExecution (0, {-100000000, -1}, ... ) == 0x0

문제 해결 전략

서버가 Hang(정지)될 때 프로세스 스택 정보를 분석합니다.

소스 코드를 분석 및 디버깅합니다.

리소스 부족을 검사합니다.

소스 코드에 디버깅 코드를 추가합니다.

운영 체제의 패치가 올바른지 검사합니다.

다음은 문제를 조사하는 동안 Hang(정지)이 발생할 수 있는 세 가지 예제입니다.

서버 프로세스가 sleep 루프에서 Hang(정지)됩니다.

truss 또는 strace 명령을 실행하여 이 문제를 조사합니다. 이 도구를 사용하여 다음을 알 수 있습니다.

sleep 시스템 함수가 다른 시스템 호출을 호출하나 이 시스템 호출이 차단됩니다. HP UNIX에서 시스템 호출은 sigtimedwait()입니다.

sleep이 시간 초과되면 운영 체제는 프로세스에게 시그널을 보내고 이 시스템 호출이 인터럽트되어 오류를 반환합니다. 오류 번호는 EAGAI입니다.

프로세스를 조사하기 위해 gdb 또는 dbx를 실행하는 경우 "where"로 생성된 출력으로부터 스택 정보에 sleep 명령이 호출된 것을 알 수 있습니다.

서버 프로세스가 대규모 데이터에 대한 데이터베이스 쿼리의 결과를 대기 중입니다.

데이터베이스와 Tuxedo가 동일한 호스트에 배포된 경우 IPC를 사용하여 통신하므로 IPC에 대한 시스템 호출에서 프로세스가 차단됩니다.
tuxedo가 소켓으로 데이터베이스에 액세스할 경우 select, insert, update 같은 SQL 문은 미리 컴파일될 때 데이터베이스 함수로 컴파일됩니다. 그러므로 SQL 요청 전송 함수는 시스템 호출 read/write로 변환됩니다.

데드락(Deadlock): 서로 다른 서버의 서비스가 서로 호출합니다.

시나리오
1. SVR_A와 SVR_B라는 이름의 두 tuxedo 서버가 있고 이들 서버에 다수의 서비스가 있다고 가정합니다. 예를 들어, SVR_A에는 SVCA1과 SVCA2라는 이름의 두 개 서비스가 있습니다. SVR_B에는 SVCB1과 SVCB2라는 이름의 두 개 서비스가 있습니다.
1. tuxedo 응용 프로그램에서 SVCA1 서비스가 SVCB1에 대해 tpcall을 호출하고 SVCB2 서비스가 SVCA2에 대해 tpcall을 호출합니다.
1. 한 대의 서버 SVR_A와 SVR_B에 대해 tmboot를 실행하고 tuxedo 클라이언트 응용 프로그램이 SVCA1과 SVCB2에 대해 동시에 tpcall을 호출하는 경우 SVR_A와 SVR_B 서버 모두 Hang(정지)될 수 있습니다.
분석
클라이언트가 서버에 대해 tpcall을 호출하는 시기를 알고 있으므로 요청 메시지는 요청 큐에 전송됩니다. msgrecv()를 호출하는 프로세스는 메시지를 큐에서 꺼내어 요청을 처리합니다. 프로세스가 tpreturn을 호출하기 전에 요청 큐에 리스닝하는 서버가 없습니다.
그러나 이 시나리오에서 클라이언트 응용 프로그램은 SVR_A와 SVR_B 모두에 대해 동시에 tpcall을 실행합니다. 두 서버는 다음과 같은 상태를 취할 수 있습니다. SVR_A는 SVR_B에 대해 tpcall을 실행할 필요가 있는 메시지를 처리할 준비가 되고(예를 들어, SVCA1이 SVCB1에 대해 tpcall 실행) 동시에 SVR_B는 SVR_A에 대해 tpcall을 실행할 필요가 있는 메시지를 처리할 준비가 됩니다(예를 들어, SVCB2가 SVCA2에 대해 tpcall 실행). 그러므로 SVR_A는 SVR_B에 메시지를 전송한 후 SVR_B가 반환할 때까지 차단합니다. 이는 SVR_B가 SVR_A에게 메시지를 전송한 후 SVR_A가 반환할 때까지 차단하는 동안 발생합니다. SVR_A 한 대와 SVR_B 한 대에 대해 tmboot를 실행하면 이 둘 모두 차단됩니다. 명백히 SVR_B는 SVR_A의 요청을 처리할 수 없고 SVR_A는 SVR_B의 요청을 처리할 수 없습니다. 그러므로 SVR_A와 SVR_B 모두가 Hang(정지)되거나 데드락(deadlock)에 빠집니다.
해결 방법
SVCA2와 SVCB1 서비스를 새 서버 두 대로 빌드하여 서로 의존하지 않도록 합니다.

페이지 맨 위

외부 리소스
다음에서 CPU 사용량을 검사하고 프로세스를 디버깅하는 데 도움이 되는 유틸리티 도구를 구할 수 있습니다.

pslist: http://www.sysinternals.com/ntw2k/freeware/pslist.shtml

strace: http://www.bindview.com/Support/RAZOR/Utilities/Windows/strace_readme.cfm

tusc: http://www.hp.com/workstations/segments/mcad/dassault/plmcc/perf_tools.html

페이지 맨 위

추가 도움말
패턴대로 작업했지만 추가 도움말이 필요한 경우 다음과 같이 할 수 있습니다.

http://support.bea.com/의 AskBEA에서 "Tuxedo server hang"으로 문제를 조회하여 게시된 다른 해결 방법을 찾아봅니다. 계약 지원 고객: 제공되는 CR 관련 정보에 액세스할 수 있는 권한으로 로그온합니다.
http://forums.bea.com에서 BEA 뉴스그룹에 보다 자세한 내용을 질문합니다.

이렇게 해도 문제를 해결할 수 없는 경우 유효한 유지보수 계약이 되어 있다면 http://support.bea.com/에 로그인하여 지원을 요청할 수 있습니다.

고객 의견

이 지원 진단 패턴 "Tuxedo 서버 Hang(정지)"이 도움이 되셨습니까? 여러분에게 꼭 필요한 정보나 지원 진단 패턴에 새로 추가하길 바라는 항목이 있으면 저희에게 알려주시기 바랍니다.

책임의 한계에 대한 고지

BEA Systems, Inc.는 사용자와 BEA 간의 유지 보수 및 지원 계약 내용에 따라 이 웹 사이트에 기술 팁과 패치를 제공합니다. BEA에서 허가한 소프트웨어와 함께 이 정보 및 코드를 사용할 수 있지만 BEA는 기술 팁 및 패치와 관련하여 어떠한 명시적이거나 암시적인 보증도 하지 않습니다.

이 문서에 참조된 상표는 해당 소유자의 자산입니다. 자세한 상표 정보를 보려면 제품 설명서를 참조하십시오.

'9. 도서관 > __사. Network' 카테고리의 다른 글

cpu error (0)	2008.11.16
Corrected Memory Error on J0304 is Persistent (0)	2008.11.16
SPARC: 64비트 객체를 처리하는 동안 발생하는 dbx 디버거 문제(6347707) (0)	2008.11.16
비정상적으로 높은 WLS의 CPU 사용량 패턴 (0)	2008.11.16
솔라리스 cdrom (0)	2008.11.12

Tuxedo 서버 Hang(정지)

'9. 도서관 > __사. Network' 카테고리의 다른 글

댓글

💲 추천 글

티스토리툴바

Tuxedo 서버 Hang(정지)

'9. 도서관 > __사. Network' 카테고리의 다른 글

볼 만한 글

댓글

💲 추천 글

티스토리툴바