文章目录
问题现象：
每天调度的一个任务在某天突然运行时长多了好几倍，平时30m左右，那天运行了4个小时多
排查思路
-
1.查看hiveserver侧
检查query提交、编译及执行的时间，是否有卡点：如由于锁导致的等待导致的执行等待长
-
2.查看yarn侧及作业日志
查看hiveserver2侧提交tez session一切正常，此时需获取applicationId来查看作业日志
作业日志首先查看am日志，检查container的分配情况是否正常，有没有因资源堵塞导致的延迟、以及container的运行失败重调度情况等
上述查看正常
查看task运行概况
搜索关键字TASK_FINISHED
发现某个map task的运行时间是其他map task的三倍(这里00是map task、01是reduce task)
查看map和reduce container的日志
接着查看这个task_1676535507899_2801404_1_00_000013的日志
这里task会变为attempt，后面添加0代表这个第一次运行
通过map container的日志发现问题：
1.通过Processing split查看这个map task要读取的文件(业务原因，小文件)特别多
同时查看reduce container的日志：
很明显 是上面map task长尾了 导致reduce task一直等待拉取map的输出导致的
初步结论
后面对比了map task的输入文件，这个container接收的明显要多，导致map task长尾，拖慢整个作业的运行时长。（这两次作业的输入文件数和数据量是差不多的）
从现在看tez的分片机制有问题？
继续排查
container数量差异大
对比这个作业两天运行的app日志，发现以下情况：分配的container数量，有问题的作业明显要少几十倍
获知这个情况后，查看am日志发现：
分片计算异常
-
问题作业
在tez计算map task的数量时，available slots的数量为0，这里YarnTaskSchedulerService日志一直打印获取的集群可用资源为0
但是通过监控查看当时集群仍有很多的可用资源，从后续的日志看，1分多钟后也获取到了正常的资源情况，但此时task数量已经计算完了并提交请求了
-
正常作业
计算map task的数量时，获取的集群资源是正常的（6516736/1591 正正好是4096M
结论
是由于一直获取不到集群资源导致，计算的container过少，某个map task处理的数据过多而长尾拖慢整个作业的运行时长。这里tez与RM通信，有以下几点怀疑：
1.网络层面：am运行的节点与RM之间网络波动
2.服务层面：RM当时无法正常响应、可能是由于gc pause等原因
3.资源层面：可能是队列资源满了或队列的父队列资源满了