大规模集群故障处理，能抗住这3个灵魂拷问算你赢

某些节点CPU负载很高影响了job任务的运行，发现有些节点的负载从9:30到现在一直很高，导致job任务执行了大概7个小时。

解决办法：

找到耗时task执行的节点，确实发现负载很高，并找到了此任务对应的进程。

查看此进程的堆栈信息，发现Full GC次数很多，时长很长大概6个小时，频繁的Full GC会使CPU使用率过高。

查看job进程详情发现，java heap内存只有820M，task处理的记录数为7400多万，造成堆内存不足频繁出发Full GC。

推荐下次执行任务时设置如下参数大小：

hive> set mapreduce.map.memory.mb=4096; 

hive> set mapreduce.map.java.opts=-Xmx3686m; 

7、NameNode切换后部分Hive表无法查询。

小集群NameNode发生切换，并出现Hive某库下的表和其有关联的表无法使用的情况报错如下：

截图报错，表明当前NameNode节点为stanby节点。经过排查发现，Hive的Metadata中有些partition列的属性还保留之前配置的NameNode location。

解决办法：

• 备份Hive所在的MySQL元数据库 # mysqldump -uRoot -pPassword hive > hivedump.sql;
• 进入Hive所在的MySQL数据库执行，修改Hive库下SDS表下的location信息，涉及条数9739行。把指定IP的location替换成nameservice ;

UPDATE SDS SET LOCATION = REPLACE(LOCATION, 'hdfs://ip:8020', 'hdfs://nameservice1') where LOCATION like 'hdfs://ip%';

• 切换NameNode验证所影响Hive表是否可用;
• 业务全方面验证 ;
• 变更影响范围：本次变更可以在线进行实施，避开业务繁忙段，对业务无影响;
• 回退方案：从备份的mysqldump文件中恢复mysql hive元数据库 mysql -uUsername -pPassword hive < hivedump.sq。

8、Spark任务运行缓慢，且经常执行报错。

产线集群提交作业执行报错,个别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。

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!