影响Hadoop集群稳定性后续
程序员文章站
2024-01-01 20:13:46
...
由于目前处理的数据量还未称的上大规模，但每个节点的压力都不小，真是稳定压倒一切呀。
在系统的作业过程中，不仅仅是关注磁盘使用量，CPU，Load，以及IOWait等指标，更重要的是深入到进程内部，来发现潜在的问题。近期一直在关注Hadoop系统的运行，我把dfshealth.jsp 的web管理页面加了一个新的指标，就是每个Node的Xceiver Count，该参数表示当前Node有多少线程数在服务w/r；另外一个很有用的指标就是每个Node的Last Contact，这个心跳包的最后更新时间一般超过3时你就得留意着是不是还会继续增长，如果持续走高，那你就得花点时间来care一下这台node各方面的压力。
Last Contact增高是各个Node出现问题的前兆，所以得相当注意，以前我曾记录过方面的问题：http://dongyajun.iteye.com/blog/627905， 后来我最终还是放弃hadoop的shell实现，改用本地脚本运行的方式，把磁盘的使用量等信息输出到临时文件中，供hadoop读取，不过这个问题并没有因此得到完全解决。
1. Node收到删除大量block的命令，请参见：https://issues.apache.org/jira/browse/HDFS-611， 升级到0.21.0版本会解决
2. Node report block给NN，这个长长也会花较长时间，如果你节点的Block够多，一般在30w+时，要花30秒左右时间，甚至更多。（默认一个小时报告一次），其实report block是不应该放到DN的 offerService中执行的，这个在0.21.0在始终未解决。
3. 在reprt block 之前，首先要从FSDataset中，获取该Node所有block列表，这个操作将花大量的时间，有时甚至要250秒甚至更多。此操作加上之后的report block方法调用，已经花了近300秒时间了。
Node长时间不发送心跳给NN产生的问题并不仅仅是该Node无冤的沦为dead node，更重要的是对客户端put的影响，虽然这种现象不会同时发生在put操作时的那几台Node上，但由于压力等诸多因素，仍然会导致Node无法正常把刚写完的block报告给NN，如果该block未报告给NN，客户端则不能成功申请新的block，如果该block是客户端最后升请的block，客户端关闭文件时就会报 Could not complete file *** retrying...异常。
解决方案：
1. DN的offerservice 中，把block report 放到单独线程中运行。
心跳和block report异步来做，对于0.21.0以下版本仍然有问题，当block report从FSDataset获取block info时，会对FSDataset类实例持有锁，由于这个操作花大量时间，会导致心跳在调用getCapacity时，被无情的BLOCKED，Last Contact仍然会增高。
2. 如果使用的低版本Hadoop，在FSDataset中，引入：
去掉FSDataset#getCapacity, #getRemaining 等方法的synchronized，改为：
在系统的作业过程中，不仅仅是关注磁盘使用量，CPU，Load，以及IOWait等指标，更重要的是深入到进程内部，来发现潜在的问题。近期一直在关注Hadoop系统的运行，我把dfshealth.jsp 的web管理页面加了一个新的指标，就是每个Node的Xceiver Count，该参数表示当前Node有多少线程数在服务w/r；另外一个很有用的指标就是每个Node的Last Contact，这个心跳包的最后更新时间一般超过3时你就得留意着是不是还会继续增长，如果持续走高，那你就得花点时间来care一下这台node各方面的压力。
Last Contact增高是各个Node出现问题的前兆，所以得相当注意，以前我曾记录过方面的问题：http://dongyajun.iteye.com/blog/627905， 后来我最终还是放弃hadoop的shell实现，改用本地脚本运行的方式，把磁盘的使用量等信息输出到临时文件中，供hadoop读取，不过这个问题并没有因此得到完全解决。
1. Node收到删除大量block的命令，请参见：https://issues.apache.org/jira/browse/HDFS-611， 升级到0.21.0版本会解决
2. Node report block给NN，这个长长也会花较长时间，如果你节点的Block够多，一般在30w+时，要花30秒左右时间，甚至更多。（默认一个小时报告一次），其实report block是不应该放到DN的 offerService中执行的，这个在0.21.0在始终未解决。
3. 在reprt block 之前，首先要从FSDataset中，获取该Node所有block列表，这个操作将花大量的时间，有时甚至要250秒甚至更多。此操作加上之后的report block方法调用，已经花了近300秒时间了。
Node长时间不发送心跳给NN产生的问题并不仅仅是该Node无冤的沦为dead node，更重要的是对客户端put的影响，虽然这种现象不会同时发生在put操作时的那几台Node上，但由于压力等诸多因素，仍然会导致Node无法正常把刚写完的block报告给NN，如果该block未报告给NN，客户端则不能成功申请新的block，如果该block是客户端最后升请的block，客户端关闭文件时就会报 Could not complete file *** retrying...异常。
解决方案：
1. DN的offerservice 中，把block report 放到单独线程中运行。
心跳和block report异步来做，对于0.21.0以下版本仍然有问题，当block report从FSDataset获取block info时，会对FSDataset类实例持有锁，由于这个操作花大量时间，会导致心跳在调用getCapacity时，被无情的BLOCKED，Last Contact仍然会增高。
"DataNode: [/sd01/hadoop/data/, …]" daemon prio=10 tid=0x08b1b800 nid=0x4cdd waiting for monitor entry [0x6df25000..0x6df25e30]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.hadoop.hdfs.server.datanode.FSDataset$FSVolumeSet.getCapacity(FSDataset.java:557)
- waiting to lock <0x74faca20> (a org.apache.hadoop.hdfs.server.datanode.FSDataset$FSVolumeSet)
at org.apache.hadoop.hdfs.server.datanode.FSDataset.getCapacity(FSDataset.java:755)
at org.apache.hadoop.hdfs.server.datanode.DataNode.offerService(DataNode.java:713)
at org.apache.hadoop.hdfs.server.datanode.DataNode.run(DataNode.java:1297)
at java.lang.Thread.run(Thread.java:619)
Locked ownable synchronizers:
- None
2. 如果使用的低版本Hadoop，在FSDataset中，引入：
//Used for synchronizing access to usage stats private Object statsLock = new Object();
去掉FSDataset#getCapacity, #getRemaining 等方法的synchronized，改为：
/**
* Return the total space used by dfs datanode
*/
public long getDfsUsed() throws IOException {
synchronized(statsLock) {
return volumes.getDfsUsed();
}
}
/**
* Return total capacity, used and unused
*/
public long getCapacity() throws IOException {
synchronized(statsLock) {
return volumes.getCapacity();
}
}
/**
* Return how many bytes can still be stored in the FSDataset
*/
public long getRemaining() throws IOException {
synchronized(statsLock) {
return volumes.getRemaining();
}
} 推荐阅读