Impala实践之五:一次系统任务堵塞记录 + 思考

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zhaodedong/article/details/52210302

前言

前段时间,imppala资源告警,各种任务失败,查询堵塞,因此公司集群升级。

这次迁移的确必须,因为当时的集群规模很小,资源太紧张了。

迁移集群后,今天集群再次出问题,导致一个下午没什么事都没干,查了一下午的错误。

事件发展

1.阶段一:下午2点17分

数据组反映集群崩溃,HUE界面不能登录,登录之后刷不出来表,当然也不能提交数据。

查看各种log日志、任务信息,发现事件发生前后有两个现象:

  • 有一个admin用户每隔一分钟提交一次insert任务,一次任务的数据量主要分两个个等级:500M、900M,他们分别需要30s和1分钟左右能完成操作。该用户每隔几次操作,会执行一次 invalidate metadata操作
  • 数据分析的小伙伴提交了很多个重复的任务,比如select *from tablename limit 100,而且有几个我很佩服的十多行的sql(目前我是写不出来)。具体的情况就是,数据分析组的三个人同时对一张表执行各种不同复杂程度的select查询,因为反映慢了点,所以反复提交了很多次,包括hue和shell端。

初步分析1: 大量任务 + 反复提交复杂查询。单个原因基本不会造成性能瓶颈,极有可能是复合原因。

2.阶段二:下午3点1分

正在排查错误,还没完全定位。集群再次罢工。这次不是很严重,是有些任务执行十分慢,以前秒出结果,这次要十几分钟。

这次从数据分析的小伙伴那里得知,他们经常做一件很厉害的事:如果一个查询结果没有很快的出来,他们会刷新页面再次提交一次,如果还没出来,会打开shell,登录集群再次提交。笑脸。

这个时候我惊奇地发现,我们cdh集群的日志时间是保留30分钟,我再扭头看我们的历史任务记录,找不到了哎。

与筛选器匹配的查询超过了能够显示的数量。尝试缩小您的搜索筛选器或者缩短您要搜索的时间范围。

嗯,我愣是没找到怎么来规定时间的范围,根据限制条件来减少搜索结果不是我想要的。我想要从几点几分到几点几分的数据。

继续找,继续找问题。

3.阶段三:下午4点

经过这半个小时的排查,我惊奇地发现一个问题,上次集群出问题的时候,有很多数据上的异常,比如io、任务数、单机任务压力。biubiubiu,好几个参数。

但是!在有些时间段,io、任务数什么的比这个还要严重,但是就是没出问题。这说明什么,说明任务失败是偶然?

初步分析2: HUE连接了其中一台impala机器,这样任务都会通过这台机器来分发,当任务多的时候肯定出问题。

4.阶段四:下午4点30

impala集群再次崩溃。

我很开心,因为历史重演,那我就可以再次拿到错误信息。干死它我会很开心。

重要:比较重要的是,在出问题的时间,我正好在任务大量提交的那台机器上执行了top命令,而且正好在一直盯着看,可以保证,impala占用内存十分小,不超过20%。在cm界面看到的内存使用情况上也一直保持稳定,没有内存不够的现象。

正要开始各种截图,各种小伙伴来找我了,好,帮忙kill任务,帮他们恢复任务。我这次狠心,把时间超过20分钟的任务全部kill掉,admin用户的任务,从服务端kill掉,一个都别跑。

然后看看一个复杂sql多久能出来,ok,基本算是秒出。

然后系统基本运行正常。

总结1

这次问题出现的原因总结如下:

  • 一个用户大量执行操作(可能会导致任务分发和回收时造成io堵塞)
  • 各种复杂查询反复提交(由于是对同一张表进行的操作,很有可能会对表造成锁)
  • 导致存放元数据的mysql锁住
  • hue提交机的性能瓶颈

其实,单独任意一个原因来说,是不足以导致集群在一个下午出现两次几乎不能正常使用的情况。而且即使出问题了,集群的各种性能指数还是比较正常的,至少内存绝对够用。

比如说一个用户执行大量的insert操作,其实这些任务本身是能正常执行的,但是当这种任务大量地执行时,很有可能会对整个集群的io造成一定的影响,这时候正好又有一定数量复杂查询的反复提交,综合起来会使集群在某个时间段内出现io或者某些表被锁住。

还有一种出错的可能:大量的insert操作或者select操作,会导致对impala的元数据库进行大量的读写,这种频繁的读写操作会造成mysql的锁表。

总结2

上一个总结是表象一点的总结。

个人感觉目前系统暴露的问题以及需要做的东西:

  • 任务提交队列,没有一个像yarn那样管理队列的功能,导致大家很high地提交自己的任务,无节制啊!
  • 权限,目前没有权限管理,大家随意提交。出问题也难定位。
  • impala集群负载均衡,这个主要体现在大量任务的提交时导致某台机器崩溃。

就目前的调研结果来看,CDH和impala自带的一些功能能满足一定的需求(比如负载均衡和队列控制),但是完成力度不够,比如用户反复提交没法控制(hue没做什么处理),队列这块使用起来不是那么顺畅(和yarn集成与否是个问题),加了haproxy后对现有的业务是否有影响(比如提交impala查询是不是都要改变?)。

暂考虑先有一个暂时解决的方案。后期可能需要重新开发一些控制系统。


2016-04-11 19:16:00 hzct

没有更多推荐了,返回首页