最近Altibase的连接数占用较多,大概30个ip,每个ip连接数为30的话,就接近1000个连接数。
下面测试上次单例、static代码改造后对连接数是否有影响。
查看Altibase连接数的方法:
select comm_name, count(*) from v$session group by comm_name order by 2 desc;
经过测试,这种查看方法是基本可靠的。
在tuxapp不启动的情况下,82ip的连接数稳定在18(除了tuxapp还有其他的应用连接),启动tuxapp后,count依然维持在18。一旦有应用调用,比如使用tuxdebug工具调用随便一个流程QAM_FEEPOLICYADDUPANDMORE,调用的tuxedo服务假设是QAM_CBS1_L1SVC,则count就会增加为19,之后重复调用该服务,依然维持在19。如果改为QAM_CBS1_L2SVC或TAM_CBS1_L1SVC服务,则会继续加一。停掉tuxapp后会恢复到18。
以上实验说明该sql统计可靠。
测试对象:
测试TAM_CBS1_L1SVC服务,min=1,max=5
停掉tuxapp后,count为18,开始大批量并发调用,一开始count为19。
Ps服务增长到2个后,count变为20
crmint-tp02:[/ngbss/tuxapp/log]$
crmint-tp02:[/ngbss/tuxapp/log]$ps -ef|grep tamcbs1l1server|grep tuxapp
tuxapp 18151 1 14 16:01 pts/8 00:00:25 tamcbs1l1server -C dom=ngbss -g 540 -i 5360 -u crmint-tp02 -U /ngbss/tuxapp/log/ulog -m 0 -A -p 1,30:2,10 -- -T
tuxapp 18957 1 47 16:03 pts/8 00:00:25 tamcbs1l1server -C dom=ngbss -g 540 -i 5361 -u crmint-tp02 -U /ngbss/tuxapp/log/ulog -m 0 -D -A -p 1,30:2,10 -- -T
crmint-tp02:[/ngbss/tuxapp/log]$
ps服务增长到3个后,count为21
此时,不再调用,服务回落到2个,count为20;服务回落为1个,count为19。
测试结束,测试结果:成功。应用不会由于大批量并发占用大量数据库连接,释放机制也OK。