我正试图分析哪些函数消耗了TeraSort Hadoop作业的最多时间。对于我的测试系统，我使用基本的1节点伪分布式设置。这意味着NameNode、DataNode、Tasktracker和Jobtracker jvm都运行在同一台机器上。
我首先使用TeraGen生成~9GB的数据，然后在其上运行tersort。在jvm执行时，我使用VisualVM对它们的执行进行了采样。我知道这不是最准确的分析器，但它是免费的，易于使用!我使用最新版本的Apache hadoop发行版，我的实验是在基于Intel Atom的系统上运行的。
当我查看VisualVM中热点方法的Self time (CPU)时，我看到java.util.zip.CRC32.update()函数占用了近40%的总时间。当我在调用树中查看这个函数时，它是由mapper的main()函数调用的，特别是当IdentityMapper.map()从HDFS读取输入文件时。实际调用CRC32.update()函数的函数是org.apache.hadoop.fs.FSInputChecker.readChecksumChunk()
我有三个问题:
-
为什么正在更新从HDFS读取块的CRC32校验和?如果我理解正确的话，一旦读取了一个块，从磁盘读取的数据与块的CRC的简单比较应该是唯一的操作，而不是生成和更新块的CRC值。
-
我查找了更新函数的源代码，它是由java.util.zip.CRC32.java文件实现的。被调用的特定函数是带有三个参数的重载update()方法。由于这个功能是在Java中实现的，是否有可能多层抽象(Hadoop, JVM, CPU指令)正在降低CRC计算的本地效率?
-
最后，我的VisualVM仪器方法或对采样结果的解释是否存在严重错误?
谢谢,
对于您的第一个问题，我认为答案是CRC文件有副本并且可能被损坏。例如，假设我们有一堆复制因子为2的文件/目录，那么可能会发生以下情况，并且需要重新计算和更新CRC:
- 删除一个副本上的元文件
- 在一个副本上截断元文件
- 破坏了一个副本上的元文件头
- 破坏任何随机偏移量和元文件的部分
- 交换两个元文件，即元文件的格式是有效的，但它们的crc与相应的数据块不匹配
如果你看一下Hadoop Common的JIRA问题，你会发现许多与CRC损坏相关的问题。
第二个问题，你能告诉我你使用的是哪个版本的Hadoop吗?