一个奇怪的故障

最近又碰到一个奇怪的问题。

我们的系统里有一个服务，负责监听前端程序发过来的数据包，并且定期写入数据库。这个程序一直跑的挺好的，但是最近发现它记录的数据跟前端服务记录的日志差别比较大。最开始怀疑是丢包造成的，但是经过测试，在高于生产环境的发包速度时，接收数据部分依然是正常的。排除这个原因后，接下来被怀疑的是Twisted的defer机制和thread调度的问题。在这个服务里，会定期起一个线程，去复制把数据记录到数据库中。这个线程是通过Twisted的deferToThread创建的。经过分析日志，这个线程启动后，可以正常进入执行函数，但是不久就像阻塞一样，不往下走了。想了很久都没想出是什么原因，期间又改用start_new_thread来创建线程，还是不行。花了几个小时看了Twisted的相关代码，感觉这部分也应该没有问题。没有什么头绪，我都准备用stackless python重写这个服务了。这时候人品又爆发了，突然觉得应该检查一下线程里数据库操作的部分，于是打开数据库相关的日志，在线看了一段时间，果然发现线程的停滞，都是因为某个数据库操作造成的。虽然有进展，不过还是想不明白。第一、这个程序跑了挺长时间，一直都没问题，为什么现在出问题了？第二、数据库服务似乎也没问题，连接数不大，不忙，数据量也不大，怎么就堵住了呢？于是查故障开始的时间，大概是上上周六的时候，回忆了一下，那天上线了一些新模块，而且，我还手很贱的更新了一下sqlalchemy。。。:(

省略中间的一些分析及测试环节，最后发现，我们在create_engine时，设置pool_recycle=3600，就是说每个链接在链接池中1小时后会被会被回收，把这个值设小一些，小于线程执行的间隔周期，就没问题了。看来是sqlalchemy的新版本中链接池部分有了什么变化。奇怪的是，同一台机器上的其他程序都没有问题。等有时间再看看它的代码吧。