我想在新的硬件堆栈上实现另一个新的Hadoop集群时提交一个奇怪的行为。
一旦安装好所有内容，只要我们尝试在HDFS上执行任何I / O操作，我们就可以在datanode日志中看到许多这样的消息：
15/01/14 22:13:07 WARN datanode.DataNode: Slow BlockReceiver write packet to mirror took 6339ms (threshold=300ms)
15/01/14 22:13:26 INFO DataNode.clienttrace: src: /10.10.5.7:17276, dest: /10.10.5.4:50010, bytes: 176285, op: HDFS_WRITE, cliID: DFSClient_NONMAPREDUCE_-832581408_1, offset: 0, srvID: af886556-96db-4b03-9b5b-cd20c3d66f5a, blockid: BP-784291941-127.0.1.1-1420922413498:blk_1073742333_1531, duration: 19383299287
其次是着名的：
java.net.SocketTimeoutException: 60000 millis timeout while waiting for channel to be ready for read (...)
我们怀疑双VLAN +绑定网络接口（2x10 GBps）是其中的一部分，但是，当然，我们仔细检查了很多这些点并且没有发现任何内容：iperf，{{1 } / dd，增加hdparm（8 GB），Xmx ...
我们只发现群集在运行HDFS（> 500毫秒，与我们的日志消息相关）时在其磁盘上有相当大的sysbench时间，但我们无法清楚地解释发生了什么。
即使你们都怀疑硬盘是造成我们麻烦的原因，有人可以解释这些日志消息吗？我们在源代码中找不到任何有趣的东西，除了在执行await时发生（有意义......）。
设定：
这是来自用户ML的交叉帖子，因为到目前为止我没有答案; - （。
答案 0 :(得分：0)
慢速HDFS我遇到同样的问题。
我设法解决了第二个错误：
java.net.SocketTimeoutException：等待时60000毫秒超时 让频道准备好阅读（...）
通过增加DataNode Java xmx。
希望这会有所帮助。
答案 1 :(得分：0)
嗯，实际上我们已经解决了这个问题。这是由于我们的网络MTU，与FS无关。我们的实验MTU太大了，导致了这种行为。回到经典价值观会使事情恢复正常。