转载

技术问题分析09(5.11)

今天一天服务运行正常,没有出现服务调用耗时很长和超时的情况,对于Weblogic的消息订阅,涉及到跨越信任的设置当前还没有在集成测试环境进行,同时当前JMS服务仍然是启用XA分布式事务处理状态。

而最近唯一做的调整就是我们对Jndi Factory连接工厂进行了拆分,对于发消息到JMS和定义JMS消费拆分为不同的连接工厂。但是昨天咨询了Oracle技术顾问,本质的问题还是不在这里。由于观察错误日志,发现的一个奇怪现象就是在我们Send Message到JMS中出现缓慢和超时的时候,同时也会发现业务系统订阅JMS消息出现超时和事务回滚。

也正是这个原因,我们一直认为是ERP的超时回滚影响到消息的发送。按道理对于JMS消息发送和接收本身就是一个异步的过程,同时又对连接工厂进行了拆分,即使JMS消息订阅出现问题也不应该影响到JMS消息分发。因此自己也在想是否是JMS的XA两阶段分布式事务处理,对于消息分发要一直等待消息订阅方取走消息后才算事务完成,针对这个假设进一步咨询了Oracle技术顾问,最终结论是两个完全异步,消息分发不会受到订阅接收的影响。因此唯一的可能假设就是,不管是消息分发端还是消息订阅端出现问题,本质都是JMS Server处于了一种不可用的状态,所以才导致了消息分发和接收都出现超时或回滚。

对于昨天发生的消息分发超时或长耗时问题,进一步对服务运行日志数据进行了分析,发现在上午10点左右的30分钟时间段里面,不仅仅是JMS消息分发,而是所有的WS Proxy代理服务都运行缓慢,耗时长或超时。而询问了业务系统后发现是业务系统原始服务出现不可用状态,同时由于我们的连接超时时间设置是10分钟,导致大量连接等待不释放,而导致了新的服务调用无法快速的从连接池获取到可用连接,而超时报错。

也就是说JMS分发服务超时本身并不是JMS Server出现了问题,而是OSB Server本身出现了大并发无效调用占有了连接,导致响应缓慢,这种响应缓慢也直接影响到了JMS分发服务。对于昨天的情况是如此,但是在前面也时不时的发生OSB服务正常,而JMS分发缓慢的情况。因此具体还有那些影响原因暂时不清楚。

由于OSB本身集群化部署,当出现跨机器访问的时候往往耗时很长,这也是我一直怀疑的另外一个原因,就是当对JMS消息发送是Remote远程操作的时候,往往容易耗时长和超时。而对于OSB和JMS都在同一台服务器的时候却很少出现这种情况。具体是否有用跨服务器资源或跨域引起的问题还需要进一步确认。

根据最近的日志监控,对于OSB集群的性能和稳定性提出了一个新的挑战,即在大并发调用下如何确保整个集群的性能和稳定性,如何实时的监测业务系统,如果业务系统服务处于不可用状态则及时的进行处理,而不是保持大量无效长连接占用资源。这些都需要进一步进行分析和处理。

原文  http://blog.sina.com.cn/s/blog_493a84550102xees.html
正文到此结束
Loading...