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服务器服务端口的方式来确定服务器和网络是否正常。