机房T和机房Y共十台前端机,Y机房请求量是T的两倍,主要用于数据查询,开始问题是Y机房tomcat 相继僵死

1) tomcat僵死处理步骤

a 检查代码,发现read through后,没有把DB数据写到缓存,增加回写代码;但单台机器每秒请求也就几十条,HBase压力很小,最终发现无效。

b 检查代码,认为跟运行几个月的动态代码在HBase使用上完全一致,所以认为业务代码层没有问题;打印堆栈信息,认为是HBase client端发现资源等待死锁的问题

c 下载0.94.2 patch,分析认为其解决了死锁问题,更新jar包部署。

 

第二周发现tomcat 日志疯狂报Interrupted错误,进程没有僵死,但有大量查询超时,达100秒,firelog每3分钟单台5000+慢查询

2) 超时处理步骤

a 认为0.94.2没有能解决问题,只是避免了死锁,但会导致Interrupted异常;使用liwei打的0.94.2的patch包上线,发现启动失败,未果(jar包中缺少版本信息,无法启动)

b 比较两个机房差异,认为Y机房网络有问题,ping HBase资源测试没有发现问题,晚上停掉T机房3台服务器,负载全在剩余两台上,达到请求量的平衡;当天晚即发现T机房也出现异常及大量超时;网络问题排除

c 第二天由于产品压力,召集开发和DBA封闭解决问题。启动tcpcopy环境做测试,尽快重现问题。计划了四个方案 

  1. 0.94.0 打patch上线

  2. tcpcopy测试0.94.2 Interrupt问题

  3.线程池去掉timeout,即不使用异步;使用后台线程2分钟检查一次HBase client的zookeeper watcher,看能否得到数据,出现问题则重新设置zookeeper;设置retry number为3次,避免重试10次,每次时间加倍导致超长查询

  4.升级zookeeper jar版本

   尝试到第三个版本终于正常,10点上线,十一点无状况,部门人员观察到2点,没有问题,第二天的数据统计99.92%请求200ms以下。通过规避异步timeout任务,不和HBase的默认异步调用发生冲突,从而解决了问题,需要从根本上做研究,彻底了解清楚原理。

总结一下,在四个方面处理有问题,需要改进

1. 网络问题  没有及早做不同机房的流量压力测试,tcpcopy测试

2. 代码逻辑问题;因为动态运行了几个月没问题,新代码跟旧代码读取部分没有差异,因此错误排除了自身问题,将问题归结于HBase client 代码。

3. 问题评估:没有评估出问题严重性,超时比率,导致最终服务恶化。

4. 人力投入问题:应早投入人力分析处理,而不是出现完全无法支撑,高层都投诉的情况下才召集处理。

posted on 2012-12-13 15:02  架构师刀哥  阅读(1098)  评论(0编辑  收藏  举报