1.问题描述

应用服务器出现客户端无法连接服务器的故障，重新启动应用程序之后解决。

客户端日志如下：

服务端日志如下：

2.故障分析

1.客户端：GP_CAT:1209: ERROR: Memory allocation error: BEMALLOC - malloc failed

该异常是无法分配内存引起的，出现该异常的情况可能是应用出现内存泄露，导致应用程序无法再获取到可用的内存。

2.服务端：CMDTUX_CAT:4747

  该异常是由于并发用户数超过licence规定的110%引起的，BBL将lockout,这是新的client无法接入应用，只有当并发用户数下降到110%后，新的client端才能接入。

3.解决方案

1.客户端：GP_CAT:1209: ERROR: Memory allocation error: BEMALLOC - malloc failed

 根据客户发的代码，发现了bug,代码如下：

上面代码中蓝色的部分是正常的tpalloc和tpfree,但是在tpinit失败之后，红色的return之前并未释放之前tpalloc的内存，这个地方会造成内存泄漏。建议在return之前加上tpfree(tpinitbuf),根据相关人员反映，应用在一段时间后就会出现这样的错误，因此怀疑故障的原因就是内存泄漏导致。

建议在代码中查找所有的tpalloc(malloc)和tpfree(free)的配对情况，避免出现内存泄漏。

2.服务端：CMDTUX_CAT:4747

这个问题是典型的并发数超过licence规定的110%，客户端三台服务器到Tuxedo服务端有225个连接，虽然使用的是短连接到服务端，但是在业务高峰期时可能会超过licence限制而导致应用无法连接到服务器。

1） 确实是并发数过高，超过了licence 110%,建议适当增加。

2） 客户端接入异常，可能是客户端无法接入，建议将环境配好，这样异常就能打印正常，初步分析，应用架构是WS模式，其通信是通过TCP的。所以可以用netstat在查看WSH连接情况，以及在服务器pclt查看客户端连接情况。

3）服务端业务挂起，可以使用pq,psr,psc组合工具查看问题所在，在服务端使用命令tmadmin，然后

a. 使用pq收集请求队列中的请求信息

b. 使用psr找出挂起服务的名字psr -q <queue_name>

    c. 使用tmadmin探查SVR_ID

 这样就可以得到问题中要得到的tuxedo server 进程ID，这个例子中的PID是16979，运行GDB命令来获得进程堆栈信息GDB<prog path>;prog path是执行文件的路径和名字。

另外，在出现故障之后，可以通过telnet到Tuxedo服务器服务端口的方式来确定服务器和网络是否正常。

可能也需要查验操作系统核心参数中，对于进程空间大小的那些设置

楼主可以把gdb的完整使用说明贴出来么? 英文的也行