占据过多ZK连接的HiveServer2导致的奇葩问题

梦里梦外; 2022-08-02 00:27 156阅读 0赞

HiveServer2的0.13版本存在一个bug，会导致该机器上的ZK连接数超过定义上限，详细可见[HIVE-8596][]描述。在我们的线上集群中，因为这个bug导致了一个有意思的故障。

线上YARN集群版本为Hadoop2.5.0-cdh5.2.0，包含7个NodeManger节点，假设为host1——host7。相关配置：可分配给容器的物理内存数量（yarn.nodemanager.resource.memory-mb）为8G，Reduce任务内存（mapreduce.reduce.memory.mb）为2G。host1上部署了HiveServer2，并且出现了HIVE-8596的bug。Reduce任务前要完成的Map任务数量（mapreduce.job.reduce.slowstart.completedmaps）为0.8.Mapreduce任务超时（mapreduce.task.timeout）为10分钟。

在06:09:54时，Application-A开始运行，其包括50个Map任务和28个reduce任务，Map中需要连接ZK。有5个Map任务分配到host1上，其余45个分配到host2——host7上。

至06:10:14时，host2——host7上的45个Map任务全部完成。不幸的是，由于HIVE-8596的缘故，host1上的任务第一次尝试全部失败，所以10分钟（mapreduce.task.timeout）后会抛出超时错误，并且准备尝试第二次，此时大约为06:20。悲催的是，在06:10:14后，由于mapreduce.job.reduce.slowstart.completedmaps阈值已经满足（45/50>0.8），所以从06:10:14到06:10:17，陆续启动了24个reduce。这些reduce任务均匀的分布在host2——host7上，即每个节点有4个。host1因为失败次数过多，已被YARN剔除在外，所以它不再接受reduce任务，剩余5个Map任务的第二次尝试也尽量不会分配给它（即使分配了，也是继续失败）。

你应该已经发现问题所在了：reduce任务占尽了host2——host7中每个节点的8G内存（yarn.nodemanager.resource.memory-mb），这导致剩余Map任务的第二次尝试无法分配，后者又导致reduce无法结束。这难道不是深恶痛绝的死锁吗？

于是，Application-A不但锁住了自己，而且锁住了之前没有完成的Application，还有之后继续启动的并需要连接ZK的Application，可谓是“前赴后续”。一直持续了几个小时，直到手动kill它后，其余Application才顺利结束。

怎么避免这个问题呢？可以借鉴以下思路及其组合：  
1. 修复HIVE-8596；  
2. 增大ZK连接数；  
3. 设置mapreduce.job.reduce.slowstart.completedmaps为1。

[HIVE-8596]: https://issues.apache.org/jira/browse/HIVE-8596