7月2日早上六点，运维反馈任务跑的慢。我们早上8点左右就定位到了问题，是hiveserver2服务延迟过高。等上班后报备需要重启服务解决问题，10点就重启完成。集群执行效率就恢复了。
但是之前积压了太多任务，导致资源队列一直是满的。而且上午任务配置的资源都非常大，在资源不够的情况下，资源不够就要一直等待资源充足才能跑。
通过问题导致的现象，断定是周五下午某些异常SQL导致了hiveserver2服务的异常延迟。并影响metastore服务。导致各个作业脚本在job提交是等待过长。多个任务的等待，占用了大量资源。导致任务积压。多个大任务的积压导致资源争抢严重。很多任务提交后并不能马上执行。处于pending状态等待资源充足后提交。最后导致任务积压越来越严重。
经过我们确认是集群到6点以后开始执行缓慢，我们确认了6点为界限确认前后任务的执行情况，发现6点之前任务执行不慢，6点以后慢，所以排除是集群的问题。所以梳理了6月30号和7月1号上线的任务，发现一个每小时跑一次的脚本。这个脚本扫描15天的实时揽收和实时退回件。占用了大量资源。次日停到这个任务发现集群还是有问题。
后面分析这个时间段运行任务使用的大表，发现有一个实时表小文件很多，而且用到的任务有50个左右。最后尝试进行定期小文件合并，集群最终恢复正常。
最终解决方案
- 后期避免在生产环境开发而抢占生产任务资源，并持续优化生产脚本是解决办法。
- 目前任务参数普遍是数据开发自己配置的。配置都偏大。几个大任务如果相遇，就会导致整个集群资源被占用，其余业务都在等待。需要持续优化参数。先把参数使用超大的
全部调整减半。后期把跑的慢的任务参数再逐渐放大。 - 目前集群在8-11点之间batch队列任务密度已经超标。最多并行跑40个任务。所以导致任务一旦资源争抢，会造成雪崩情况并持续恶化。需要调整这段时间的调度任务。
- 在周六补数据期间，在11点过后，资源队列已经空闲，但是长时间没有补数的任务上来。我建议后期可以优化一套补数调度逻辑，利用好现有资源，否则只要有任务积压，不能快速的对核心业务进行调度，也会造成错失补数时机。
- 通过这次6月30号的问题反思，对于目前生产任务上线的工作，平台组是被游离在外的，但是由于异常脚本上线对集群的影响，平台组还是要承担相应的责任。目前对于上线脚本的管控，增加了北斗的上线流程页面，对于脚本上线的管控是远远不够的。三季度我们的智能运维平台将开发一个统一调用工具。其中包含了对参数的智能评估，权限管控，运行资源统计，调用审计日志等功能。将任务参数统一管理起来，这样资源使用透明可控，可预估运行任务数量，后期可自动化管理资源调配。
网友评论