hadoop调度组件oozie无压力时莫名高负载，问题定位、源码分析、解决方案

目录

介绍说明

问题：oozie集群时常莫名高负载

问题描述

问题定位思路

问题出现

源码分析

解决方案

总结

---

介绍说明

        首先呢，第一点我想说明的是，这是一个我们公司的一个大数据中台，cdh6.3，oozie5.1.0，整个技术架构，组件选型啥的我都没参与，其次这个问题和我也没有直接关系，我只是看见群里整天嚷嚷，抱着对技术好奇和敬畏的心态，也想来参与一下这个事情，请不要吐槽为什么选oozie这个组件或者垃圾怎么样的，请关注如何分析问题，定位问题，解决问题，换个中间件一样能举一反三

问题：oozie集群时常莫名高负载

问题描述

        3节点oozie集群，闲时莫名高负载，一开始以为是节点数量不够，随即加节点，症状不缓解，把高负载的节点重启后，马上瞬间cpu打满，就差把服务器搞冒烟了，即使把节点移除nginx路由不参与调度请求再重启依然如此，该症状持续一年多排查不出来，一直以为是业务服务频繁调用oozie接口导致，已经在改造的路上了，只是最近这个问题暴露得比较严重，等不及改造完成了，需要紧急排查

问题定位思路

        我压根就没用过这玩意，说实话我有点懵，然后和同事沟通，他们也尝试做过一些优化，现在集群已经扩展到9节点，只有十几个调度任务时依然能把cpu打满。其实我的想法很简单，就看高负载的时候jvm状态，到底是哪个线程在忙，在忙什么

        我注意到一点，CDH给oozie默认有这么一个jvm参数，-XX:MaxGCPauseMillis=20，我当时就猜想，会不会是这个设置太小，导致GC回收量不够，频繁GC。后来想了想又不对，闲时没有 内存压力，应该不会因为这个引起，随即打消猜想

问题出现

        OK，运维大佬跟我说cpu要爆了，服务器马上冒烟了，我马上让他开arthas，首先瞅一眼内存值属于正常范围，堆正常，元空间正常，那么不会引起G1的Full GC这个也没问题，然后输入命令thread -n 3，好了问题暴露

        显示当前最忙碌的三个线程，可以看到这个家伙cpugUsage占用到91.52%，其次调用堆栈，定位到streamJobLog方法，还有一个ZKLogStreamingService，可以推测可能是集群间的一些同步行为，随即去翻看源码，我看到这Servlet，doGet，凉了呀，这家伙是个古董

源码分析

        说一下，oozie源码下依赖的话，需要在settings.xml加这两个东西

         找到我们的问题入口，ZKXLogStreamingService，这个是oozie要起集群的时候要加的插件类，先看下类定义

        其实我感觉问题有点眉目了，这家伙在集群间同步日志，同时通过tcpdump抓包，过滤出集群节点之间的ip请求，可以证实这个问题，集群内部确实在调这个获取日志的接口，具体为啥，我也不知道，我推测是想让用户在任意一个oozie节点都能查看完整的日志吧

        ok，往下看

        注意，这个read就是实际他读取的log日志文件

         其实我觉得看到oozie-app.log的时候基本可以知道是oozielog日志了

 

 

         那我觉得基本看到这里，可以确定oozie确实是在集群内同步log日志，并且他还是在文件内正则匹配一些内容

解决方案

        我随即让运维大佬看看oozie的log目录下有多少文件有多大，好家伙，27g，一个文件小的几十m，大的几百m，好了把所有节点的日志一清负载瞬间下来了，没有再高过

总结

        我发表一下对oozie源码的评价吧，Servelet这个确实比较老，但是垃圾也不至于，他里面的代码架构设计以及实现思路等，还是比较贴合目前的一些主流中间件源码的，各种内存队列，各种异步，等等。