前段时间写个领导的关于timesten数据库频繁hang掉的分析

最近一段时间嘉讯网关和mtn3app服务器相继出现timesten不能连接的现象，最终导致timesten服务停掉，只能重新启动服务器，其实前段时间也发生过几次但是由于我们发现的及时，停掉部分程序后系统可以恢复正常。我下面把我经过几次分析timesten日志文件后我的理解说一下，由于最近比较忙加上timesten相关的文档和个使用的企业实在太少，从其他渠道获得的信息太少，我的分析不一定准确，谁有别不同看法大家可以互相讨论争取解决这个问题，我们现在的业务量不大，如果业务量上来后系统出故障的频率估计还会增加。

 

我对故障的分析：
    timesten处理Client/Server时由一个server daemon 进程负责调度，然后衍生 一个独立的 child 进程 和client连接。
    我分析日志的时候发现每当有一个新的连接请求或断开请求时，都由一个server daemon都进行相应的处理（具体原理没有找到资料），但是肯定是有开销的，在某些时间段为会出现类似这样的提示
    Waiting for in-flux to clear (now reason 3=disconnect pid 8572 nwaiters 215 count 150 ds /opt/TimesTen/emay)
    意思我没有完全理解，但是3=disconnect pid 8572 nwaiters 215 count 150我认为可以理解为进程8572正在请求断开连接，目前等待server daemon处理的队列为215 ，count好像是该进程等待服务器处理的次数（应该有个机制定期这些等待的进程去请求自己的操作）
    当nwaiters达到一定数量的时候，timesten就出现异常不能正常工作，timesten服务进程出现异常后系统就等于崩溃了，如果我们发现的早，及时停掉那些需要连接的服务，过段时间后系统可能就正常了。
   
    但是我没有搞明白这种Client/Server连接方式的开销有多大，另外因为我们的系统已经运行了很长时间，并没有很频繁的出现这种故障，因为如果这种机制开销很大的话，timesten的并发就有问题了，不过有一点可以确认当出现这种故障时日志里都是大量的连接请求。因此我认为我们的连接数过多影响了server daemon处理速度，当并发访问很多的某一时刻系统就出现问题或bug，过大的连接/断开请求导致系统最后崩溃

 

我对解决故障的几个建议：

 

1，最大限度地减少连接，尤其是Client/Server方式，timesten的文档中明确写着连接数过多将肯定直接影响系统性能，目前有的是客户连接的一个连接进程打开timesten的10多个连接。
2，能用Direct Driver Connection不用Client/Server连接
3，事务不要太大，大事务如果失败需要回滚操作很占资源。
4，事务时间不要太长，如果事务对某个表进行锁定，务必会影响系统性能
5，另外我们重启服务的时候一定要看重启前的那个进程号重启后是否还存在，因为我们的连接在没有增加新的程序的情况下经常连接数增    加很多
6，定期执行的脚本间隔时间加长一些，尤其在高峰期，目前的对那几个日志表的unload操作是每分钟一次（为了适用原来苏工的分发流程    ）还有就是曹磊的和郭瑞的定期脚本，有的都是一分钟一次，不知道能不能调整，例如 曹磊的脚本每一分钟执行一次，由于这个文件     放到/etc/cron.minutely下，所以实际的执行频率小于1分钟。
7，我们程序访问timesten的机制或连接机制是否统一（单只Client/Server连接），我在分析日志的时候发现发现有的进程连接成功后又断开，然后重新连接
8，我们查询工具等程序使用的连接方式是否合理，如果同时访问的用户多少对timesten的影响也许会有影响，能否采用应用服务器来连接数据库的方式
9，文档中有一些关于开发方面优化的东西，如果谁有时间可以再研究一下，看看我们还有没有优化的空间
10，升级timesten到新版本，最好能模拟做一个压力测试，也许老的版本在处理连接或并发方面本身就不太好，被oracle收购后性能估计会有改善，我看到7.02版本的帮助里已经没有了goodpractices文档

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

转载于:http://blog.itpub.net/48361/viewspace-253113/