ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 【TimesTen】记一次临时空间不断被消耗的处理思路

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

原创 Linux操作系统 作者:okayleo 时间:2011-12-22 18:08:44 0 删除 编辑
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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-06-07

  • 博文量
    29
  • 访问量
    110367