大局限集群妨碍处理赏罚，能抗住这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。

（编辑：湖南网）

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