大规模集群故障处理，能抗住这3个灵魂拷问算你赢
|
产线集群提交作业执行报错,个别Task执行耗时超过2h: ERROR server.TransportChannelHandler: Connection to ip:4376 has been quiet for 120000 ms while there are outstanding requests. Assuming connection is dead; please adjust spark.network.timeout if this is wrong.  根因分析： 报错表象为shuffle阶段拉取数据操作连接超时。默认超时时间为120s。 深入了解Spark源码：在shuffle阶段会有read 和 write操作。 首先根据shuffle可使用内存对每一个task进行chcksum，校验task处理数据量是否超出shuffle buffer 内存上限。该过程并不是做全量chcksum，而是采用抽样的方式进行校验。 其原理是抽取task TID ，与shuffle内存校验，小于shuffle内存上限，则该区间的task都会获取 task data 遍历器进行数据遍历load本地，即HDFS Spark中间过程目录。 这样会导致一些数据量过大的task成为漏网之鱼，正常来说，数据量过大，如果被校验器采样到，会直接报OOM，实际情况是大数据量task没有被检测到，超出buffer过多，导致load时，一部分数据在内存中获取不到，进而导致连接超时的报错假象。 解决方案： 1)调优参数配置： spark.shuffle.manager(sort)，spark.shuffle.consolidateFiles (true)，spark.network.timeout(600s)。报错解决，运行耗时缩短一小时。 2)excutor分配内存从16g降为6g。内存占用节省三分之二，运行耗时增加一小时。 9、某HBase集群无法PUT入库问题处理。 集群情况介绍：HDFS总存储 20+PB，已使用 75+%，共 600+ 个 DN 节点，大部分数据为 2 副本(该集群经历过 多次扩容，扩容前由于存储紧张被迫降副本为 2)，数据分布基本均衡。集群上只承载了HBase数据库。 故障描述：因集群部分 DN 节点存储使用率非常高(超过 95%)，所以采取了下线主机然后再恢复 集群中这种办法来减轻某些 DN 存储压力。 且集群大部分数据为 2 副本，所以在这个过程 中出现了丢块现象。通过 fsck 看到已经彻底 miss，副本数为 0。 因此，在重启 HBase 过程中，部分 region 因 为 block 的丢失而无法打开，形成了 RIT。 对此问题，我们通过 hadoop fsck –delete 命令清除了 miss 的 block。然后逐库通过 hbase hbck –repair 命令来修复 hbase 在修复某个库的时候在尝试连接 ZK 环节长时间卡死(10 分钟没有任何输出)，被迫只能 中断命令。 然后发现故障表只有 999 个 region，并且出现 RIT，手动 assign 无效后，尝试了重启库及再次 repair 修 复，均无效。 目前在 HDFS 上查看该表 region 目录总数为 1002 个，而 Hbase UI 上是 999 个，正常值为 1000 个。 问题处理：后续检查发现在整个集群的每张 HBase 表都有 region un-assignment 及 rowkey 存在 hole 问题(不是单张表存在问题)。 运行 hbase hbck -details -checkCorruptHFiles 做集群状态检查，检查结果如下： （编辑：PHP编程网 - 湛江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
