问题描述
在 Tuxedo 应用程序中，Tuxedo 中的进程无法完成它们的当前工作、不响应新的请求且通常还会占用少量的 CPU 资源。对于异常高 CPU 占用率问题，请参考“异常高 CPU 占用率支持模式”。

为什么发生此问题？
通常服务器挂起是因为缺少某些资源。由于缺少资源或资源上有互斥锁，进程无法获取所需的资源，也就不能对新请求做出响应。例如，一个想要使用共享内存的进程会等待，直到某个进程通过发出信号释放锁定，如果没有释放，等待的进程就会挂起。可能的原因：
死锁

资源阻塞

休眠循环

超时

异常高 CPU 占用率 -- 请参考“异常高 CPU 占用率支持模式”。
故障探查
此故障探查的目的是搜索挂起服务器的堆栈信息，然后对其进行分析以找出服务器挂起的原因。

如何确定服务器是否挂起？故障探查的步骤将是：
使用 Tuxedo 管理工具“tmadmin”。 

使用命令“pq”检查 Tuxedo 队列中的请求。

使用命令“psr”检查 Tuxedo 服务器的状态。 

使用操作系统专有的实用程序检查此 Tuxedo 服务器在操作系统中的 CPU 占用情况。 

使用操作系统调试工具（如 truss、strace、gdb、dbx 等）查明服务器具体是在哪一个系统调用或 API 上挂起的。 

或通过“kill”到进程的“SIGABRT”信号生成挂起服务器的二进制核心文件转储。通过使用调试工具调试二进制核心文件可以查明进程在何处挂起。请参考二进制核心文件转储支持模式。 

对于有关收集服务器挂起的数据的特定操作信息，请根据您的操作系统执行以下步骤。

运行“tmadmin”来检查服务器状态。 
1) 使用“pq”来收集请求队列中的请求信息。

例如：echo pq | tmadmin

可以使用下列 Shell 脚本来协助进行数据收集：

输出将会是：

查看“#Queued”列的值时您会发现，某些服务器在很长时间内只增不降。请记录这些服务器的队列名称。

上例中，可疑的服务器是 simpserv，队列名称为：00001.00100。

2) 使用“psr”检查服务器状态。

这样可以显示正在处理客户端请求的服务器。第四列为服务器的 SRV_ID。

在本例中，simpserv 正在处理“TOUPPER”服务，其 SRV_ID 为 100。

3) 运行“tmadmin”，将 verbose 设置为开启并使用 SRV_ID 探查服务器。

然后即可获取可疑的 Tuxedo 服务器的进程 ID。其 PID 为 16979。
运行 ps 命令来确认 Tuxedo 服务器的 PID。 

运行 prstat 来探查此进程的 CPU 占用率： 

运行 pstack 命令来检查线程堆栈信息。 
pstack 命令可以列出特定进程的线程堆栈信息。堆栈中的“main”函数将是运行时系统调用的起始点，而且堆栈可以协助您确定 Tuxedo 服务器具体是在哪一个系统调用或 API 上挂起的。

例如，可以在以下堆栈信息中了解到，服务器是在系统调用“sleep”中挂起的。

运行 tmadmin 命令来检查服务器状态。（与 Solaris 上相同。） 
运行 ps 命令来检查服务器状态。 
ps -e -o pid,user,sz,pcpu,state,args | grep <process_name> 或 <PID> 

列 4“%CPU”表示服务器的 CPU 占用率。
列 5“S”列出进程状态，详细含义如下：
D  无法中断的休眠（通常为 IO）
R  可运行（在运行队列上）
S  休眠中
T  已跟踪或已停止
Z  失效进程（“僵”进程）
运行 top 命令，列出服务器进程的 CPU 占用率。 

运行 gdb 命令来获取进程堆栈信息 

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 命令来探查挂起服务器。进入 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 命令，获取服务器的进程 ID (PID) 

下面是输出示例：

$ 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  不存在
S  休眠中
W  等待中
R  运行中
I  中间
Z  已终止
T  已停止
X  增长中
运行 tusc 命令，探查进程的系统调用。 
可从以下 url 下载 HP Unix 上的工具“tusc”：
http://www.hp.com/workstations/segments/mcad/dassault/plmcc/perf_tools.html

使用 tusc 可以获取有关进程系统调用的所有信息。HP UNIX 还提供了使用 tusc 打包的“truss”，其命令行格式如下：

“-d”参数表示列出所有具有时间戳的系统调用。

查看下面的 truss 输出时您可以发现：
服务器进程先是阻塞在 API sigtimedwait 中，一秒钟后，一个信号（返回到 EAGAIN）中断了此系统调用，接着系统函数“time”取得了当前时间，然后调用 sigtimedwait 函数，开始下一个循环。这时您就知道了，进程是在函数“sleep”的循环中挂起的。 

运行 ipcs 命令，探查队列中的消息。 
示例：ipcs -qob   （输出 QNUM 的第 7 列列出了消息编号） 

查明只增不降的 QNUM 的消息队列 ID。
运行 tmadmin 命令，探查此消息队列 ID 的服务器。 

psr.txt 将包含像下面这样的两行：

verbose 开启时，psr 命令可以列出 Tuxedo 服务器的详细信息，其中包括进程 ID。 

获取的 PID 为 2008。
运行 prstat 命令，获取此服务器的 PID 和 CPU 占用率。 
可以在 Windows 中使用 pslist 工具，获取挂起进程的“CPU Time”。可以从以下网址下载“pslist”命令工具： http://www.sysinternals.com/ntw2k/freeware/pslist.shtml
示例：pslist <PID> 或 <进程名称> 

运行 strace 命令，探查进程堆栈信息。 
可从以下网址下载“strace”命令工具： http://www.bindview.com/Support/RAZOR/Utilities/Windows/strace_readme.cfm。 

故障排除策略 
分析服务器挂起时的进程堆栈信息。

分析和调试源代码。

检查资源缺乏情况。

在源代码中添加更多的调试代码。

���查操作系统的补丁是否正确。

以下是探查此问题时可能会发生挂起的三种示例情况：
1. 服务器进程在休眠循环中挂起。
2. 服务器进程在等待涉及大量数据的数据库查询的结果。 
3. 死锁：不同服务器中的服务相互调用

服务器进程在休眠循环中挂起
运行 truss 或 strace 来探查此问题。使用这些工具可以发现：
系统函数 sleep 调用了另一个系统调用，而该系统调用处于阻塞状态。（在 HP UNIX 中，该系统调用是 sigtimedwait()。）
休眠超时后操作系统将向进程发送一个信号，接着该系统调用被中断并返回错误。错误编号为 EAGAI。
如果运行 gdb 或 dbx 来探查进程，则可在由“where”产生的输出的堆栈信息中找到调用的 sleep 命令。

服务器进程在等待涉及大量数据的数据库查询的结果
如果在同一主机中部署数据库和 Tuxedo，则它们将通过 IPC 进行通信，因此可能会出现进程在有关 IPC 的系统调用处阻塞。 
如果 Tuxedo 通过套接字访问数据库，则预编译时将把 select、insert、update 这样的 SQL 语句编译到数据库函数中。因此发送 SQL 请求的函数将把意愿转换为系统调用读写。 

死锁：不同服务器中的服务相互调用
情况 
假设有两个名为 SVR_A 和 SVR_B 的 Tuxedo 服务器，而且它们都有许多服务。例如，SVR_A 包括两个名为 SVCA1 和 SVCA2 的服务。SVR_B 包括两个名为 SVCB1 和 SVCB2 的服务。
在我们的 Tuxedo 应用程序中，服务 SVCA1 tpcall SVCB1，服务 SVCB2 tpcall SVCA2。
如果只 tmboot 一个服务器 (SVR_A) 且只有一个服务器 (SVR_B) 和我们的 Tuxedo 客户端应用程序在同时 tpcall SVCA1 和 SVCB2，则服务器 SVR_A 和 SVR_B 都可能会挂起。

分析 
正如我们所知，客户端 tpcall 服务器时，请求消息将被发送到服务器的请求队列中。随后调用 msgrecv() 的进程将使此消息出队并处理请求。在此进程调用 tpreturn 前，没有服务器会监听请求队列。
不过，在本例中，客户端应用程序同时 tpcall SVR_A 和 SVR_B。它们可能会具有下列状态。SVR_A 已做好处理消息的准备，但需要 tpcall SVR_B（例如，SVCA1 tpcall SVCB1），同时 SVR_B 也做好了处理消息的准备，但需要 tpcall SVR_A（例如，SVCB2 tpcall SVCA2）。因此，SVR_A 向 SVR_B 发送消息时会发生阻塞，直至其得到 SVR_B 的响应为止。与此同时，SVR_B 向 SVR_A 发送消息时也会发生阻塞，直至其得到 SVR_A 的响应为止。我们只想 tmboot 一个 SVR_A 和一个 SVR_B，而现在二者都发生了阻塞。显然，SVR_B 无法处理 SVR_A 的请求，SVR_A 也无法处理 SVR_B 的请求。因此，SVR_A 和 SVR_B 都会挂起或陷入死锁状态。

解决办法 
将服务 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