【TimesTen】记一次临时空间不断被消耗的处理思路

Command> dssize;
  PERM_ALLOCATED_SIZE:      4194304
  PERM_IN_USE_SIZE:         130299
  PERM_IN_USE_HIGH_WATER:   569181
  TEMP_ALLOCATED_SIZE:      524288
  TEMP_IN_USE_SIZE:         27247
  TEMP_IN_USE_HIGH_WATER:   62451

一般情况下，TEMP_IN_USE_SIZE不会被使用太多，TEMP_ALLOCATED_SIZE分配PERM_ALLOCATED_SIZE的1/10即可。
但是昨天一台网关的TEMP_IN_USE_SIZE空间一直在上涨，直至接近分配值，导致timesten处理变慢，最后导致其它应用无法抓取数据。
同事小强提供的信息是MT和RECEIVE_PACK两张表均有几十万的数据排队等待处理。而一般情况下这两张表不应该有这么多数据的堆积，除非业务高峰，但昨天显然算不上高峰。
这已经是该网关第二次出现同样的问题，上次重启tt，释放了临时空间。不能每次靠重启来解决问题，需要查找一下问题的根本原因。
top命令查看，负载不是很高。
打开应用的debug，看到日志里显示这两张表上就是update mt ...; insert ... select * from mt where ...; delete from mt where ...，
检查相关列，都有索引，与其他网关一致，看来不是因为索引不到位导致处理不过来。
ttxactadmin gw1查看锁情况，发现RECEIVE_PACK表上有很多tx锁长时间的持有不释放，其中有本地程序也有远程连接过来的程序。
我们有几套相同的网关，查看了其他的网关tt，MT和RECEIVE_PACK表都没有积压多少数据，ttxactadmin gw1也几乎没有长久持有的锁信息。
与其他网关比较，唯一区别就是这个网关上有远程连接过来的程序连接TimesTen，会不会是这些远程进程长时间对表RECEIVE_PACK持有锁，导致其它进程等待，从而进一步导致TimesTen的临时空间不断被消耗呢？
停掉远程连过来的程序后，使用dssize查看临时空间情况，发现空间在回收，只是速度有点慢，起码比停之前有变化了。
由于是生产系统，业务不能长时间停，杀掉所有进程，重启了tt。并协调维护人员尽快将远程进程去掉。

小结：虽然本次没有直接定位就是远程进程导致，不过还是取得了一些进展，等远程进程不再连接的时候再看一下。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12355989/viewspace-713798/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12355989/viewspace-713798/