gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具
    • SVG转PDF/Word
    • SVG转Draw.io可二次编辑格式
    • js代码混淆
    • json格式化及任意折叠展开
    • PDF常用工具

由于datanodeUuid值不一致导致DataNode数据目录出现Failure

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  
  • 作者: east
  • ( 页面64 )
bug清单 2月 28,2021

由于datanodeUuid值不一致导致DataNode数据目录出现Failure

由于datanodeUuid值不一致导致DataNode数据目录出现Failure

现象描述

在“dfs.datanode.data.dir”中添加新目录后,发现老的目录出现failure。

由于datanodeUuid值不一致导致DataNode数据目录出现Failure

可能原因

新老目录下“VERSION”文件里的“datanodeUuid”值不一致。

定位思路

查看DataNode的日志文件,检查是否有InconsistentFSStateException异常信息,是否显示“datanodeUuid”不一致。

heartbeating to 9-96-101-251/172.18.0.111:25000 | org.apache.hadoop.hdfs.server.common.InconsistentFSStateException: Directory /export4/BigData/datanode/dn3 is in an inconsistent state: 
Root /export4/BigData/datanode/dn3: DatanodeUuid=2a8c2266-7d3f-428c-b47f-6c7e2500bdc5, does not match 3d61ca33-c3ba-4c73-998a-7667c747545d from other StorageDirectory. | DataStorage.java:375

处理步骤

  1. 进入“新目录/current/”,查询“VERSION”文件中的“datanodeUuid”值。 #Tue Jul 05 22:23:04 CST 2016 storageID=DS-7c410c98-29bc-49de-b3dd-87cd48d4f7d3 clusterID=myhacluster cTime=0 datanodeUuid=3d61ca33-c3ba-4c73-998a-7667c747545d storageType=DATA_NODE layoutVersion=-56
  2. 进入“老目录/current/”,将“VERSION”文件中的“datanodeUuid”修改成1查询到的“datanodeUuid”值。
  3. 重启DataNode。

参考信息

DataNode启动时,会从数据目录中的“VERSION”文件中读取“datanodeUuid”值,并将该值写入到系统的DataStorage对象中。每个DataNode对应一个“datanodeUuid”值,即同一个DataNode上的所有目录使用同一个“datanodeUuid”值。

该问题中,删除老目录,添加新目录时,“VERSION”文件并没有被拷贝到新目录中,重启DataNode后,新目录中的“VERSION”文件由format操作生成,并自动生成了一个新的“datanodeUuid”值。

将老目录加回到“dfs.datanode.data.dir”中,并且位于新目录之前,重启DataNode后,DataNode会先从老目录中加载“VERSION”文件,读取其中的“datanodeUuid”值,并写入到系统的DataStorage对象中。再从新目录中的“VERSION”文件中读取“datanodeUuid”值并与系统的DataStorage对象中的“datanodeUuid”值作对比时,由于新目录中的“datanodeUuid”值是后来重新生成的,与老目录中的不同,所以系统会抛出“datanodeUuid”不匹配的InconsistentFSStateException异常。

作者 east
bug清单 2月 28,2021

Datanode报InvalidProtocolBufferException异常

Datanode报InvalidProtocolBufferException异常

现象描述

DataNode无法发送block报告给NameNode。以下为DataNode日志信息:

java.lang.IllegalStateException: com.google.protobuf.InvalidProtocolBufferException: 
Protocol message was too large.  May be malicious.  Use CodedInputStream.setSizeLimit() 
to increase the size limit exception

可能原因

此类故障发生在DataNode向NameNode发送block报告时。HDFS是专门为大文件设计的,所以为了防止其用于小文件上,限制了每个卷的block报告的体积。

定位思路

以防这类异常发生,用户可指定多种“dfs.datanode.data.dir”,在多个卷内将block分散开来,block报告消息的体积将会变小。

在运行的环境中遇到此类异常时,Hadoop目前无法做到自动完成上述修复。

处理步骤

  1. 关闭相关的DataNode。
  2. 使用mv命令将block副本和meta对从“dfs.datanode.data.dir”目录移动到新目录下,同时确保块在磁盘间移动时subdir目录的结构始终完全保持不变。 例如,如果block副本和meta对是在“/data/1/dfs/dn/current/BP-1788246909-10.10.1.202-1412278461680/current/finalized/subdir0/subdir1/”目录下,若想要将其移动到“/data/5/disk”下,必须移到相同的子目录结构,即“/data/5/dfs/dn/current/BP-1788246909-10.10.1.202-1412278461680/current/finalized/subdir0/subdir1/”。 如果目录结构发生改变,移动后的DataNode将不能定位副本。
  3. 重启DataNode。
作者 east
bug清单 2月 28,2021

资源异常导致HDFS进入安全模式

资源异常导致HDFS进入安全模式

现象描述

在性能环境上验证性能指标时HDFS进入安全模式。 NameNode日志中出现下列信息:

WARN org.apache.hadoop.hdfs.server.namenode.NameNodeResourceChecker: Space available on volume 'null' is 0, 
WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: NameNode low on available disk space. Entering safe mode.

可能原因

  1. 参数“dfs.namenode.name.dir”配置目录的磁盘空间不足。
  2. 底层网络文件系统出现了不可用的情况导致的,如网络不稳定等。

定位思路

  1. 查看参数“dfs.namenode.name.dir”配置目录的磁盘空间是否足够。
  2. 查看底层网络文件系统是否异常,如网络不稳定等。
  3. 查看NameNode日志中是否出现类似“NameNode low on available disk space. Entering safe mode”的日志。

处理步骤

  1. 查看参数“dfs.namenode.name.dir”配置目录的磁盘空间是否足够。
  2. 修复底层网络文件系统之后(网络稳定之后),手动退出安全模式。执行hdfs dfsadmin -safemode leave命令手动退出安全模式。
作者 east
bug清单 2月 28,2021

Hbase由于网络故障引起的InvalidToken异常

由于网络故障引起的InvalidToken异常

现象描述

安全模式下,在执行Mapreduce或者Spark等程序时,可能出现如下异常导致的任务执行失败:

2015-12-07 12:46:17,607 WARN [htable-pool1-t1] 
org.apache.hadoop.hbase.ipc.AbstractRpcClient: Exception encountered 
while connecting to the server :
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.token.SecretManager$InvalidToken): Unknown master key for token (id=7)

可能原因

由于网络故障导致客户端和服务端的token不一致。

定位思路

无。

处理步骤

  1. 重新启动发生故障的RegionServer和客户端程序。
作者 east
bug清单 2月 28,2021

在hbck命令输出中出现“Found lingering reference file”

在hbck命令输出中出现“Found lingering reference file”

现象描述

残留的引用文件指的是连接hfile的引用文件,这个hfile在HDFS中是不存在。

Hback工具报出以下错误:

hbase/bin> hbase hbck
2016-03-08 17:57:55,858 WARN  [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
INFO: Watching file:/home/pankaj/v1r2cxx/hbase/hbase/conf/log4j.properties for changes with interval : 60000
HBaseFsck command line options:

2016-03-08 17:57:58,179 INFO  [main] util.HBaseFsck: Checking and fixing region consistency
ERROR: Region { meta => null, hdfs => hdfs://10.10.106.212:8020/hbase/data/default/t1/7fbfdb516dff6013009143c4ba22cb89, deployed => , replicaId => 0 } 
on HDFS, but not listed in hbase:meta or deployed on any region server
2016-03-08 17:57:58,218 INFO  [main] util.HBaseFsck: Computing mapping of all store files

2016-03-08 17:57:58,253 INFO  [main] util.HBaseFsck: Validating mapping using HDFS state
ERROR: Found lingering reference file
hdfs://10.10.106.212:8020/hbase/data/default/t1/7fbfdb516dff6013009143c4ba22cb89/cf1/64d2e118ab1347a59aeb90f206853dc5.8fcda14355e599b20e8ea7f66f86b9d0
Summary:
Table hbase:meta is okay.
    Number of regions: 1
    Deployed on:  host-10-10-106-212,16020,1457430545905
Table hbase:acl is okay.
    Number of regions: 1
    Deployed on:  host-10-10-106-212,16020,1457430545905
Table t1 is okay.
    Number of regions: 2
    Deployed on:  host-10-10-106-212,16020,1457430545905
Table hbase:namespace is okay.
    Number of regions: 1
    Deployed on:  host-10-10-106-212,16020,1457430545905
2 inconsistencies detected.
Status: INCONSISTENT
2016-03-08 17:57:58,418 INFO  [main] client.ConnectionManager$HConnectionImplementation: Closing master protocol: MasterService
2016-03-08 17:57:58,418 INFO  [main] client.ConnectionManager$HConnectionImplementation: Closing zookeeper sessionid=0x10101ea9abf0181

可能原因

在一个故障场景,子region A在table目录下已经成功创建,但是在创建子region B的过程中region server出故障了。因此split region失败了并且在table目录的文件系统留下一个孤立的子目录。

当打开region,只清理”.split”目录,而不是孤立的子regions,这些孤立的子regions在先前失败的split操作过程中可能被移到table目录。因此将来,如果父region split成功,那么之前失败的子region A的引用hfile将会无效,hback将会报出以上错误。

定位思路

无。

处理步骤

  1. Hback工具提供命令-fixReferenceFiles来使这样残留的引用文件保留在其他位置。由于这会引起其他的不一致,请使用hbck -repair命令来解决这些不一致。 hbase hbck -repair <tableName>
  2. 运行hbck命令来复查-repair命令是否修复了所有的不一致。 hbase hbck 如果hback命令输出结果不一致,请重复1。

参考信息

Hbck命令有很多其他选项,请运行以下命令来获得更详细的用法。

hbase hbck -help

作者 east
bug清单 2月 28,2021

Hbase大量Region处于RIT,HMaster出现异常,日志出现Packet len6080218 is out of range!

大量Region处于RIT,HMaster出现异常,日志出现Packet len6080218 is out of range!

现象描述

大量Region处于RIT,HMaster出现异常,HMaster不停主备倒换,但是无法恢复,日志中打印如下:

Packet len6080218 is out of range!

可能原因

大量Region处于RIT,在读取处于RIT的Region信息时,超出“jute.maxbuffer”默认值,导致读取失败。

定位思路

无。

处理步骤

设置“jute.maxbuffer”的值,该值的设置可以参考以下关系:

1MB理论上最多能容纳6990个Region。

作者 east
bug清单 2月 28,2021

Hbase磁盘故障,RegionServer重启之后,Region offline

磁盘故障,RegionServer重启之后,Region offline

现象描述

磁盘故障,RegionServer重启之后Region offline。

可能原因

磁盘故障,在Region重新分配过程中,被分配的RegionServer重启,Region分配失败,Region offline。

定位思路

排查磁盘故障原因,以及RegionServer被重启的原因。

处理步骤

  1. 排除故障原因,恢复磁盘故障。
  2. 当磁盘故障恢复,HBase健康状态恢复,执行hbase hbck -fixAssignments使Region恢复上线。
作者 east
bug清单 2月 28,2021

Hbase加载数据失败

现象描述

超过32个HFile加载到一个Region下的Family时,出现如下错误信息:

Exception in thread "main" java.io.IOException: Trying to load more than 32 hfiles to one family of one region
        at org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.doBulkLoad(LoadIncrementalHFiles.java:302)
        at org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.run(LoadIncrementalHFiles.java:884)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:75)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:90)
        at org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.main(LoadIncrementalHFiles.java:890)

可能原因

加载数据时,默认支持的最大Hfile数为32个。当一个Region下的一个Family超过32个HFile时,会出现此错误。

定位思路

无。

处理步骤

  1. 执行LoadIncrementalHFiles命令时添加参数,并给“hbase.mapreduce.bulkload.max.hfiles.perRegion.perFamily”参数设置一个最大值。该值表示Family下可生成的最多的HFile的个数。 例如,执行如下命令使系统支持40个HFile。cd <hbase_client>/HBase/hbase bin/hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles -Dhbase.mapreduce.bulkload.max.hfiles.perRegion.perFamily=40 <hdfs://storefileoutput> <tablename>
作者 east
bug清单 2月 28,2021

Hbase由于网络或操作系统故障引起的找不到hbase:meta异常

由于网络或操作系统故障引起的找不到hbase:meta异常

现象描述

在执行MapReduce或者Spark等程序时,可能出现如下异常导致的任务执行失败:

Caused by: java.net.SocketTimeoutException: callTimeout=60000, callDuration=60304: row '' 
on table 'hbase:meta' at region=hbase:meta,,1.1588230740, hostname=host1,21302,1448886113294, seqNum=0
at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:159)
at org.apache.hadoop.hbase.client.ResultBoundedCompletionService$QueueingFuture.run(ResultBoundedCompletionService.java:64)
... 3 more

可能原因

  • HDFS服务不可用。
  • ZooKeeper上存储的meta region位置数据和实际不符。

定位思路

无。

处理步骤

  1. 确认HDFS服务是否可用,如果HDFS服务不可用,请先排除HDFS故障。
  2. 如果HDFS服务无故障,从HBase原生网页中找到hbase:meta表所在节点,重启该节点的RegionServer。
作者 east
bug清单 2月 28,2021

运行Spark Streaming应用时出现内存不足的问题

运行Spark Streaming应用时出现内存不足的问题

现象描述

某Spark Streaming应用对每个批次不大于3000M的数据进行wordcount,即使每个executor给予30G内存,执行一段时间后还是会发生内存不足。

日志信息如下:

2016-02-04 20:19:43,458 | ERROR | [Thread-29] | Uncaught exception in thread Thread[Thread-29,5,main] | org.apache.spark.Logging$class.logError(Logging.scala:96)
java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:3236)
        at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
        at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
        at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
        at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1877)
        at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1786)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1189)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
        at org.apache.spark.serializer.JavaSerializationStream.writeObject(JavaSerializer.scala:43)
        at org.apache.spark.serializer.SerializationStream.writeAll(Serializer.scala:153)
        at org.apache.spark.storage.BlockManager.dataSerializeStream(BlockManager.scala:1190)
        at org.apache.spark.storage.BlockManager.dataSerialize(BlockManager.scala:1199)
        at org.apache.spark.streaming.receiver.WriteAheadLogBasedBlockHandler.storeBlock(ReceivedBlockHandler.scala:173)

可能原因

Spark Streaming从Kafka接收数据的方式有两种:

  • Receiver-based Approach
  • Direct Approach (No Receivers)

上述问题只有Receiver-based的方式会出现,Direct的方式不会出现该问题。

在Spark Streaming应用中,每一个批次会生成一个job。如果job的处理时间大于批次的时间间隔(批次时间间隔在Spark Streaming应用中定义),则从数据源(即Kafka)接收的数据就会累积,最后造成任务的不断积压,导致executor端内存溢出。

定位思路

无。

处理步骤

当出现如上问题时,建议可采用如下两种方法进行调整,两种方法可同时使用:

  • 适当缩短批次的时间,使得接收到的数据量不要太大。
  • 根据任务量增大内存,使得job的处理时间加快,保证job的处理时间比批次的时间短。
作者 east
bug清单 2月 28,2021

行Spark SQL语句时,出现joinedRow.isNullAt的空指针异常

执行Spark SQL语句时,出现joinedRow.isNullAt的空指针异常

现象描述

在执行Spark SQL语句时,出现“joinedRow.isNullAt”的空指针异常,异常信息如下所示。

6/09/08 11:04:11 WARN TaskSetManager: Lost task 1.0 in stage 7.0 (TID 10, vm1, 1): java.lang.NullPointerException
        at org.apache.spark.sql.catalyst.expressions.JoinedRow.isNullAt(JoinedRow.scala:70)
        at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificMutableProjection.apply(Unknown Source)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator$$anonfun$generateProcessRow$1.apply(TungstenAggregationIterator.scala:194)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator$$anonfun$generateProcessRow$1.apply(TungstenAggregationIterator.scala:192)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.processInputs(TungstenAggregationIterator.scala:372)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.start(TungstenAggregationIterator.scala:626)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1.org$apache$spark$sql$execution$aggregate$TungstenAggregate$$anonfun$$executePartition$1(TungstenAggregate.scala:135)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$3.apply(TungstenAggregate.scala:144)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$3.apply(TungstenAggregate.scala:144)
        at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:64)
        at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
        at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
        at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
        at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
        at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
        at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:75)
        at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:42)
        at org.apache.spark.scheduler.Task.run(Task.scala:90)
        at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:253)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

可能原因

由如下日志信息可知,该错误是由于内存不足,导致buffer在申请内存时申请失败返回为null,对null进行操作就返回了空指针异常。

当集群中内存相关的关键配置项的值设置的比较小时,例如设置为如下所示的值:

spark.executor.cores = 8

spark.executor.memory = 512M

spark.buffer.pageSize = 16M

此时,执行任务会出现内存申请失败返回null的异常,关键日志如下:

6/09/08 11:04:11 WARN TaskSetManager: Lost task 1.0 in stage 7.0 (TID 10, vm1, 1): java.lang.NullPointerException
        at org.apache.spark.sql.catalyst.expressions.JoinedRow.isNullAt(JoinedRow.scala:70)

定位思路

在使用Spark SQL时,需要满足如下条件:

spark.executor.memory * spark.shuffle.memoryFraction *spark.shuffle.safetyFraction / (num * spark.executor.cores) > spark.buffer.pageSize

“spark.shuffle.memoryFraction”默认值为“0.2”。“spark.shuffle.safetyFraction”默认值为“0.8”。“spark.buffer.pageSize”默认值为“16M”。

常数num的经验取值为8,根据不同的SQL语句取值不同,每个task最多可以去申请16次pageSize,所以num的最大值为16。将公式中的参数num设置为16时,即可满足Spark SQL出现问题的所有场景。但通常情况下8即能满足绝大多数的场景要求。

处理步骤

根据executor日志提示信息,您可以通过调整如下两个参数解决此问题。在客户端的“spark-defaults.conf”配置文件中调整如下参数。

  • spark.executor.memory:增加executor的内存,即根据实际业务量,适当增大“spark.executor.memory”的参数值。需满足公式:spark.executor.memory > spark.buffer.pageSize * (num * spark.executor.cores) / spark.shuffle.memoryFraction / spark.shuffle.safetyFraction
  • spark.executor.cores:减小executor的核数,即减小executor-cores的参数值。需满足公式:spark.executor.cores < spark.executor.memory / spark.buffer.pageSize / num * spark.shuffle.memoryFraction * spark.shuffle.memoryFraction。

在调整这两个参数时,需满足spark.executor.memory * spark.shuffle.memoryFraction *spark.shuffle.safetyFraction / (num * spark.executor.cores) > spark.buffer.pageSize公式,在内存充足的情况下,建议直接将常数num设置为16,可解决所有场景遇到的内存问题。

作者 east
bug清单 2月 28,2021

Spark出现Unable to acquire异常

出现Unable to acquire异常

现象描述

执行Spark SQL语句时,出现java.io.IOException: Unable to acquire […] bytes of memory异常,如下:

WARN TaskSetManager: Lost task 578.2 in stage 30.0 (TID 228063, 8-5-203-1, 244): java.io.IOException: Unable to acquire 16777216 bytes of memory
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.acquireNewPage(UnsafeExternalSorter.java:354)
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.<init>(UnsafeExternalSorter.java:141)
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.create(UnsafeExternalSorter.java:109)
    at org.apache.spark.sql.execution.UnsafeExternalRowSorter.<init>(UnsafeExternalRowSorter.java:68)
    at org.apache.spark.sql.execution.TungstenSort.org$apache$spark$sql$execution$TungstenSort$$preparePartition$1(sort.scala:146)
    at org.apache.spark.sql.execution.TungstenSort$$anonfun$doExecute$3.apply(sort.scala:169)
    at org.apache.spark.sql.execution.TungstenSort$$anonfun$doExecute$3.apply(sort.scala:169)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.prepare(MapPartitionsWithPreparationRDD.scala:50)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD$$anonfun$tryPrepareParents$1.applyOrElse(ZippedPartitionsRDD.scala:83)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD$$anonfun$tryPrepareParents$1.applyOrElse(ZippedPartitionsRDD.scala:82)
    at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33)
    at scala.collection.TraversableLike$$anonfun$collect$1.apply(TraversableLike.scala:278)
    at scala.collection.immutable.List.foreach(List.scala:318)
    at scala.collection.TraversableLike$class.collect(TraversableLike.scala:278)
    at scala.collection.AbstractTraversable.collect(Traversable.scala:105)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD.tryPrepareParents(ZippedPartitionsRDD.scala:82)
    at org.apache.spark.rdd.ZippedPartitionsRDD2.compute(ZippedPartitionsRDD.scala:97)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.ZippedPartitionsRDD2.compute(ZippedPartitionsRDD.scala:99)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:75)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:42)
    at org.apache.spark.scheduler.Task.run(Task.scala:90)
    at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:253)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745).

一定概率下,当以上WARN连续导致同一个Task失败4次后,会导致Job级别的失败,如下:

org.apache.spark.SparkException: Job aborted due to stage failure: Task 537 in stage 30.0 failed 4 times, most recent failure: Lost task 537.3 in stage 30.0 (TID 228865, 8-5-202-7, 650): java.io.IOException: Unable to acquire 16777216 bytes of memory
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.acquireNewPage(UnsafeExternalSorter.java:354)
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.<init>(UnsafeExternalSorter.java:141)
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.create(UnsafeExternalSorter.java:109)
    at org.apache.spark.sql.execution.UnsafeExternalRowSorter.<init>(UnsafeExternalRowSorter.java:68)
    at org.apache.spark.sql.execution.TungstenSort.org$apache$spark$sql$execution$TungstenSort$$preparePartition$1(sort.scala:146)
    at org.apache.spark.sql.execution.TungstenSort$$anonfun$doExecute$3.apply(sort.scala:169)
    at org.apache.spark.sql.execution.TungstenSort$$anonfun$doExecute$3.apply(sort.scala:169)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.prepare(MapPartitionsWithPreparationRDD.scala:50)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD$$anonfun$tryPrepareParents$1.applyOrElse(ZippedPartitionsRDD.scala:83)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD$$anonfun$tryPrepareParents$1.applyOrElse(ZippedPartitionsRDD.scala:82)
    at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33)
    at scala.collection.TraversableLike$$anonfun$collect$1.apply(TraversableLike.scala:278)
    at scala.collection.immutable.List.foreach(List.scala:318)
    at scala.collection.TraversableLike$class.collect(TraversableLike.scala:278)
    at scala.collection.AbstractTraversable.collect(Traversable.scala:105)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD.tryPrepareParents(ZippedPartitionsRDD.scala:82)
    at org.apache.spark.rdd.ZippedPartitionsRDD2.compute(ZippedPartitionsRDD.scala:97)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.ZippedPartitionsRDD2.compute(ZippedPartitionsRDD.scala:99)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:75)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:42)
    at org.apache.spark.scheduler.Task.run(Task.scala:90)
    at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:253)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)               

可能原因

目前Spark Shuffle内存管理存在缺陷:原理上讲,ShuffleMemoryManger给Task分配内存时,根据运行时的Task个数去动态切分可分配的总内存,当一个Task结束后,运行时的Task个数相应减少,此时ShuffleMemoryManger会根据减少后的Task个数重新切分可分配的内存。在某些情况下,在新的Task起来之前,已运行的Task将内存全部占走。

在该场景下,新的Task会申请不到内存,然后触发溢出逻辑溢出当前UnsafeExternalSorter所占的内存,并重试申请动作,但由于其本身所占内存为0,溢出后还是分配不到内存,抛出上述异常,表示Task失败。

失败的Task会进行重试,若其他的Task及时地释放了内存,则Task会重试成功,Job不会失败。如果此时其他Task未及时释放内存,则Task重试失败。当该Task连续4次失败后导致Job失败。

定位思路

无。

处理步骤

进入Spark客户端的“$Spark_Client/conf/spark-defaults.conf”配置文件修改对应配置以规避此问题。

  • 方法一:设置spark.executor.cores=1,将单个Executor内的并行度将为1可规避此问题。
  • 方法二:增大spark.sql.shuffle.partitions,可降低该异常出现的概率。
  • 方法三:减小spark.buffer.pageSize,可降低该异常出现的概率
作者 east

上一 1 … 63 64 65 … 93 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 解决gitlab配置Webhooks,提示 Invalid url given的问题
  • 如何在Chrome中设置启动时自动打开多个默认网页
  • spark内存溢出怎样区分是软件还是代码原因
  • MQTT完全解析和实践
  • 解决运行Selenium报错:self.driver = webdriver.Chrome(service=service) TypeError: __init__() got an unexpected keyword argument ‘service’
  • python 3.6使用mysql-connector-python报错:SyntaxError: future feature annotations is not defined
  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?

文章归档

  • 2025年12月
  • 2025年10月
  • 2025年8月
  • 2025年7月
  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (45)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (5)
  • 大数据开发 (497)
    • CDH (6)
    • datax (4)
    • doris (31)
    • Elasticsearch (15)
    • Flink (79)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (41)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (100)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (39)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (71)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (8)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.