记一次Hadoop集群数据上传缓慢案例分析

本文为博主原创文章，转载需获取作者授权。

项目场景

手上管理的其中一个Hadoop集群，承接着大量的数据流量，一直以来运行平稳，最近突然发现集群有时会出现MR作业运行缓慢，put文件至HDFS偶发速度慢的问题，像大数据集群这种问题，有点疑难杂症的味道，本次也是经历了10多个小时的定位才真正把问题解决。

问题现象

1. 使用客户端节点执行hdfs dfs -put文件上传至HDFS偶发慢，集群内部节点put文件也出现偶发速度慢；查看Hadoop集群相关监控指标未见异常；
2. 业务反馈入库作业有积压，数据积压于上传接口机；
3. 查看某MR作业发现101个Map Task运行缓慢，101个Map Task分布在多个节点，数据量与成功跑完的Task无较大差异，暂无法定位到是否是某些节点的问题。

定位过程

1. 查看hadoop集群相关监控指标，namenode rpc连接数、rpc队列，hdfs使用情况、小文件数均为正常，集群服务没问题；
2. 使用fsck命令查看多个上传慢文件的block块所在的dn节点是否重叠来判断是否存在问题节点，发现涉及的ip较多，没有明显规律；

   hdfs fsck –block FILENAME –files –blocks -locations

3. 尝试查看所有DataNode服务日志，看是否有异常日志；执行egrep -o “Slow.*?(took|cost)” /data01/var/log/hadoop/hdfs/*log | sort | uniq -c，发现Slow BlockReceiver write packet to mirror took 提示远高于其他信息，初步判定是网络问题；
   
4. 因为慢现象为偶发现象，所以不可能是所有节点都慢，怀疑是部分节点慢，进一步分析Slow BlockReceiver write packet to mirror took的信息，发现某几个的Slow BlockReceiver write packet to mirror took 提示明显高于其他节点，达到100多万，该批节点很有可能存在问题。此处需要说明：如果所有节点的Slow日志大致一样，那无法说明问题；
   
5. 既然怀疑是网络问题，于是对相关节点进行丢包率和网速测试；发现某一网段部分节点丢包率严重达到60%，且网速仅有100多KB/s，这对于10GB带宽的业务网显然不正常；注意：ping 测试丢包率时需使用ping大包的方式进行，使用ping –s指定包的大小，否则无法测出丢包率，谨记；
   
6. 联系网络运维的同事协助排查网络问题，多次配合交换机工程师追踪包的传输过程，发出网络测试，经数次测试后发现一台交换机有数据丢失现象；
7. 交换机工程师对交换机多次测试，确定了某一网段接入交换机的一个上联光口存在丢包情况，将丢包的交换机口down掉，ping丢包测试和网速测试随即正常；
8. 交换机工程师对交换机光口进行报障修复；
9. 业务侧和平台侧同时测试，再未见put任务慢现象。

解决方案

既然是交换机带来的网络问题，自然是通过修复交换机硬件故障来解决。
本次运维事件也暴露出了网络运维同事对交换机监控的不足，如果网络侧能够及时发现交换机硬件故障，也不会对上层集群产生这么大的影响。

案例小结

虽然故障原因很简单，但是本案例的分析过程值得我们总结。事后我对Hadoop源码提示Slow BlockReceiver write packet to mirror 警告的代码段进行了分析，发现其为数据块横向复制过程中超时所打印，证实了前面的猜想。

    //First write the packet to the mirror:
    if (mirrorOut != null && !mirrorError) {
      try {
        long begin = Time.monotonicNow();
        packetReceiver.mirrorPacketTo(mirrorOut);
        mirrorOut.flush();
        long duration = Time.monotonicNow() - begin;
        if (duration > datanodeSlowLogThresholdMs) {
          LOG.warn("Slow BlockReceiver write packet to mirror took " + duration
              + "ms (threshold=" + datanodeSlowLogThresholdMs + "ms)");
        }
      } catch (IOException e) {
        handleMirrorOutError(e);
      }
    }

源码地址：https://github.com/apache/hadoop/blob/master/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/BlockReceiver.java

同时，我们可以总结到：

1. 集群作业慢首先查看集群监控指标是否正常，是否存在冷热数据、小文件问题；其次排查网络状态；
2. DataNode慢日志可大致说明是否是网络问题；下表对常见Slow日志进行了说明；
3. 排查网络需使用ping大包和网速测试，需多次测试；
4. 建议网络侧加强对网络层的监控，提前发现网络层硬件问题。

日志	原因
Slow BlockReceiver write packet to mirror	为将数据写入对端的DataNode耗时，判断为对端的DataNode慢导致
Slow manageWriterOsCache	调用os接口将数据写入缓存慢
Slow flushOrSync或Slow BlockReceiver write data to disk cost	这表示在将块写入OS缓存或磁盘时存在延迟

---