You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
通过jstack诊断得知是刷新YARN Fair Scheduler相关方法所导致(详见下图)。由于YARN Fair Scheduler是临界资源故该方法被加了锁(sychronized),该线程拿着锁进入了TIMED_WAITING(sleeping)状态!既然是TIMED_WAITING,该线程应该是会在有限时间内回到RUNNABLE状态的,等了十多分钟后发现该线程依然处于TIMED_WAITING状态,此时已有其他为了获取锁进入了BLOCKED状态(详见下图),大量的线程无法结束,资源得不到释放,可能引发OOM 或 too many open files 错误,也增加了线程的调度的开销。
http://stackoverflow.com/questions/9734384/default-timeout-for-httpcomponent-client
http://stackoverflow.com/questions/3000214/java-http-client-request-with-defined-timeout
问题的发现
在In(一个大数据运营管理系统)中创建storm/jstorm/hbase(on slider)集群时都出现页面卡住状态,无法成功创建。而创建storm/jstorm/hbase集群的代码中有一个共同的操作是创建YARN 队列(通过调用ambari rest接口实现),怀疑与此相关,故试了下单独创建一个YARN 队列,果然也出现了页面卡住的状态,等待了一会后chrome浏览器会出现下图所示界面。去ambari web 页面上看了刷新队列操作历史,发现该操作的时间变慢了(50秒左右),从而可以怀疑是刷新队列时间变慢引出该问题。
问题修复(第一次)
为了验证上面的猜想,找熟悉ambari相关同事解决了该问题后,可以成功创建storm/jstorm/hbase了。但是,rest接口调用导致页面长时间卡住也是不科学的,为了进一步确认该问题,检查了之前通过jstack pid拿到的信息,如下图红框中所示,创建队列的线程拿着锁进入到TIMED_WAITING(sleeping)状态,其他试图获取该锁的线程都进入到了BLOCKED状态,等待sleeping的线程能够醒来释放锁。既然是TIMED_WAITING状态,那理论上来说一定时间是会醒过来的,由于已经知道是哪部分代码导致的了,看了代码中使用了的是Apache 的HttpClient来发起rest请求,但是未设置超时机制,即便如此也应该会有一个默认超时时间,查看相关资料和代码,httpclient不会添加一个默认超时时间,会按照os的tcp_fin_timeout http 短连接
复现问题
由于ambari同事已被修复了该问题,但为了验证in修复是否有效,需要先复现刷新Fair Scheduler慢的问题,咨询了下相关同事尝试短时间内复现问题未果后,最终通过脚本同时发送大量刷Fair Scheduler命令来延长infinite中的rest调用的时间。ambari中的显示如下:
此时,在infinite中的界面中进行创建yarn服务的操作(该操作中需要刷新fair scheduler),问题复现了,通过jstack pid拿到线程的堆栈信息,找到我们我感兴趣的线程如下图红框所示,该线程就是会调用rest接口刷新队列的,
问题修复(第二次)
通过jstack诊断得知是刷新YARN Fair Scheduler相关方法所导致(详见下图)。由于YARN Fair Scheduler是临界资源故该方法被加了锁(sychronized),该线程拿着锁进入了TIMED_WAITING(sleeping)状态!既然是TIMED_WAITING,该线程应该是会在有限时间内回到RUNNABLE状态的,等了十多分钟后发现该线程依然处于TIMED_WAITING状态,此时已有其他为了获取锁进入了BLOCKED状态(详见下图),大量的线程无法结束,资源得不到释放,可能引发OOM 或 too many open files 错误,也增加了线程的调度的开销。
ambari刷新YARN Fair Scheduler速度变慢(可以理解为某个方法调用较慢),在infinite(大数据运营管理系统)中会调用ambari的rest接口刷新fai scheduer,Fair Scheduler 为临界资源,所以为刷新Fair Scheduler的方法加了锁(synchronized),但因为rest接口变慢导致infinite页面卡死显然不合理,猜测是锁未及时释放。
问题探究
通过
解决问题
由于已经定位到了相关用户代码,看了段代码后发现创建的httpclient未设置超时,以为是这个原因导致线程迟迟未能释放同步锁,
The text was updated successfully, but these errors were encountered: