问题现象：

每天调度的一个任务在某天突然运行时长多了好几倍，平时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.资源层面：可能是队列资源满了或队列的父队列资源满了