标签：
前段时间，imppala资源告警，各种任务失败，查询堵塞，因此公司集群升级。
这次迁移的确必须，因为当时的集群规模很小，资源太紧张了。
迁移集群后，今天集群再次出问题，导致一个下午没什么事都没干，查了一下午的错误。
数据组反映集群崩溃，HUE界面不能登录，登录之后刷不出来表，当然也不能提交数据。
查看各种log日志、任务信息，发现事件发生前后有两个现象：
select *from tablename limit 100,而且有几个我很佩服的十多行的sql（目前我是写不出来）。具体的情况就是，数据分析组的三个人同时对一张表执行各种不同复杂程度的select查询，因为反映慢了点，所以反复提交了很多次，包括hue和shell端。初步分析1： 大量任务 + 反复提交复杂查询。单个原因基本不会造成性能瓶颈，极有可能是复合原因。
正在排查错误，还没完全定位。集群再次罢工。这次不是很严重，是有些任务执行十分慢，以前秒出结果，这次要十几分钟。
这次从数据分析的小伙伴那里得知，他们经常做一件很厉害的事：如果一个查询结果没有很快的出来，他们会刷新页面再次提交一次，如果还没出来，会打开shell，登录集群再次提交。笑脸。
这个时候我惊奇地发现，我们cdh集群的日志时间是保留30分钟，我再扭头看我们的历史任务记录，找不到了哎。
与筛选器匹配的查询超过了能够显示的数量。尝试缩小您的搜索筛选器或者缩短您要搜索的时间范围。嗯，我愣是没找到怎么来规定时间的范围，根据限制条件来减少搜索结果不是我想要的。我想要从几点几分到几点几分的数据。
继续找，继续找问题。
经过这半个小时的排查，我惊奇地发现一个问题，上次集群出问题的时候，有很多数据上的异常，比如io、任务数、单机任务压力。biubiubiu，好几个参数。
但是！在有些时间段，io、任务数什么的比这个还要严重，但是就是没出问题。这说明什么，说明任务失败是偶然？
初步分析2： HUE连接了其中一台impala机器，这样任务都会通过这台机器来分发，当任务多的时候肯定出问题。
impala集群再次崩溃。
我很开心，因为历史重演，那我就可以再次拿到错误信息。干死它我会很开心。
重要：比较重要的是，在出问题的时间，我正好在任务大量提交的那台机器上执行了top命令，而且正好在一直盯着看，可以保证，impala占用内存十分小，不超过20%。在cm界面看到的内存使用情况上也一直保持稳定，没有内存不够的现象。
正要开始各种截图，各种小伙伴来找我了，好，帮忙kill任务，帮他们恢复任务。我这次狠心，把时间超过20分钟的任务全部kill掉，admin用户的任务，从服务端kill掉，一个都别跑。
然后看看一个复杂sql多久能出来，ok，基本算是秒出。
然后系统基本运行正常。
这次问题出现的原因总结如下：
其实，单独任意一个原因来说，是不足以导致集群在一个下午出现两次几乎不能正常使用的情况。而且即使出问题了，集群的各种性能指数还是比较正常的，至少内存绝对够用。
比如说一个用户执行大量的insert操作，其实这些任务本身是能正常执行的，但是当这种任务大量地执行时，很有可能会对整个集群的io造成一定的影响，这时候正好又有一定数量复杂查询的反复提交，综合起来会使集群在某个时间段内出现io或者某些表被锁住。
还有一种出错的可能：大量的insert操作或者select操作，会导致对impala的元数据库进行大量的读写，这种频繁的读写操作会造成mysql的锁表。
上一个总结是表象一点的总结。
个人感觉目前系统暴露的问题以及需要做的东西：
就目前的调研结果来看，CDH和impala自带的一些功能能满足一定的需求（比如负载均衡和队列控制），但是完成力度不够，比如用户反复提交没法控制（hue没做什么处理），队列这块使用起来不是那么顺畅（和yarn集成与否是个问题），加了haproxy后对现有的业务是否有影响（比如提交impala查询是不是都要改变？）。
暂考虑先有一个暂时解决的方案。后期可能需要重新开发一些控制系统。
2016-04-11 19:16:00 hzct
标签：
原文地址：http://blog.csdn.net/zhaodedong/article/details/52210302
