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

分类归档bug清单

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

  • 首页   /  
  • 分类归档: "bug清单"
  • ( 页面4 )
bug清单 2月 27,2021

Spark任务运行失败,ApplicationMaster出现物理内存溢出异常

Spark任务运行失败,ApplicationMaster出现物理内存溢出异常

现象描述

在YARN上运行Spark任务失败,ApplicationMaster出现物理内存溢出异常。报错内容如下:

2016-05-12 19:27:18,078 | WARN  | Container Monitor | Container [pid=205193,containerID=container_1462240697997_3649_01_000001] is running beyond physical memory limits. Current usage: 4.5 GB of 4.5 GB physical memory used; 6.8 GB of 22.5 GB virtual memory used. Killing container.

可能原因

日志中显示“Killing container”,直接原因是物理内存使用超过了限定值,YARN的NodeManager监控到内存使用超过阈值,强制终止该container进程。

定位思路

无。

处理步骤

在Spark客户端“spark-defaults.conf”配置文件中增加如下参数,或者在提交命令时添加–conf指定如下参数,来增大memoryOverhead。

  • spark.yarn.driver.memoryOverhead:设置堆外内存大小(cluster模式使用)。
  • spark.yarn.am.memoryOverhead:设置堆外内存大小(client模式使用)。
作者 east
bug清单 2月 27,2021

Spark大数据计算时出现“Channel空闲超时”

大数据计算时出现“Channel空闲超时”

现象描述

在10节点集群,30T数据量下,执行tpcds测试时,出现如下错误。

Connection to 10.10.10.1 has been quiet for 123450 ms while there are still 5 outstanding requests. Assuming connection is dead; please adjust spark.network.timeout if this is wrong.

可能原因

当Map Server繁忙时,Reduce Client发出请求,得不到响应。当等待时间超过一个阈值时,出现错误。默认的时间为120秒。

定位思路

无。

处理步骤

上述问题是在request个数很大时发生的,属于正常现象。解决措施有两种:

  • 将spark.shuffle.io.connectionTimeout参数调大。10节点、30T数据的TPCDS测试中设置为2000s,运行正常。此参数与spark.network.timeout配合使用,优先使用spark.shuffle.io.connectionTimeout参数设置的值。如果spark.shuffle.io.connectionTimeout未设置,则使用spark.network.timeout的参数值。
  • 调大spark.shuffle.io.serverThreads来解决,将此参数的值设置为core个数的两倍。
作者 east
bug清单 2月 27,2021

Executor日志中显示物理内存超限

Executor日志中显示物理内存超限

现象描述

在如下场景下,会导致Executor日志中显示物理内存超限:

  • 在100T数据下,执行TPC-H 21号测试用例时,出现如下错误信息。 Spark Executor的日志信息如下2016-03-07 15:17:10,221 | ERROR | [SIGTERM handler] | RECEIVED SIGNAL 15: SIGTERM | org.apache.spark.util.SignalLoggerHandler.handle(SignalLogger.scala:57) YARN NodeManger的日志信息如下ERROR | [dispatcher-event-loop-28] | Lost executor 471 on 10-196-33-3: Yarn deallocated the executor 471 (container container_e04_1456978747173_0063_01_000473) | org.apache.spark.Logging$class.logError(Logging.scala:75) 2016-03-07 15:05:24,704 | WARN | [Reporter] | Container killed by YARN for exceeding memory limits. 22.0 GB of 22 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. | org.apache.spark.Logging$class.logWarning(Logging.scala:71)
  • 在100T数据下,执行TPC-H 22号测试用例时,出现如下错误信息。 Spark Driver日志信息如下:org.apache.spark.shuffle.FetchFailedException: java.lang.OutOfMemoryError: Direct buffer memory at org.apache.spark.storage.ShuffleBlockFetcherIterator.throwFetchFailedException(ShuffleBlockFetcherIterator.scala:339) at org.apache.spark.storage.ShuffleBlockFetcherIterator.next(ShuffleBlockFetcherIterator.scala:324) at org.apache.spark.storage.ShuffleBlockFetcherIterator.next(ShuffleBlockFetcherIterator.scala:52) at scala.collection.Iterator$$anon$14.hasNext(Iterator.scala:389) at scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:327) at scala.collection.Iterator$$anon$13.hasNext(Iterator.scala:371) at scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:327) at org.apache.spark.util.CompletionIterator.hasNext(CompletionIterator.scala:32) at org.apache.spark.InterruptibleIterator.hasNext(InterruptibleIterator.scala:39) at org.apache.spark.util.collection.ExternalSorter.insertAll(ExternalSorter.scala:217) at org.apache.spark.shuffle.hash.HashShuffleReader.read(HashShuffleReader.scala:110) at org.apache.spark.rdd.ShuffledRDD.compute(ShuffledRDD.scala:90) at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:301) at org.apache.spark.rdd.RDD.iterator(RDD.scala:265) at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38) at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:301) at org.apache.spark.rdd.RDD.iterator(RDD.scala:265) at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38) at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:301) at org.apache.spark.rdd.RDD.iterator(RDD.scala:265) 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:229) 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) Caused by: io.netty.handler.codec.DecoderException: java.lang.OutOfMemoryError: Direct buffer memory at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:234) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111) … 1 more Caused by: java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:658) at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:645) at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:228) at io.netty.buffer.PoolArena.allocate(PoolArena.java:212) at io.netty.buffer.PoolArena.reallocate(PoolArena.java:358) at io.netty.buffer.PooledByteBuf.capacity(PooledByteBuf.java:121) at io.netty.buffer.AbstractByteBuf.ensureWritable(AbstractByteBuf.java:251) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:849) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:841) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:831) at io.netty.handler.codec.ByteToMessageDecoder$1.cumulate(ByteToMessageDecoder.java:92) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:228) … 10 more

可能原因

由于Executor使用的堆外内存超限,导致被NodeManager终止任务或者报“申请不到堆外内存”错误。

作者 east
bug清单 2月 27,2021

Spark当Collect超大结果集到Driver时出现异常

当Collect超大结果集到Driver时出现异常

现象描述

当Collect超大的结果集到Driver端时会出现如下两种错误:

  • 出现OOM错误。日志信息如下:java.lang.OutOfMemoryError: GC overhead limit exceeded 16/01/25 12:08:56 WARN AkkaRpcEndpointRef: Error sending message [message = RemoveBroadcast(69,true)] in 1 attempts org.apache.spark.rpc.RpcTimeoutException: Recipient[Actor[akka://sparkDriver/user/BlockManagerMaster#366390194]] had already been terminated.. This timeout is controlled by spark.rpc.askTimeout at org.apache.spark.rpc.RpcTimeout.org$apache$spark$rpc$RpcTimeout$$createRpcTimeoutException(RpcEnv.scala:214) at org.apache.spark.rpc.RpcTimeout$$anonfun$addMessageIfTimeout$1.applyOrElse(RpcEnv.scala:229) at org.apache.spark.rpc.RpcTimeout$$anonfun$addMessageIfTimeout$1.applyOrElse(RpcEnv.scala:225) at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33) at scala.util.Failure$$anonfun$recover$1.apply(Try.scala:185) at scala.util.Try$.apply(Try.scala:161) at scala.util.Failure.recover(Try.scala:185) at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324) at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324) at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32) at org.spark-project.guava.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:293) at scala.concurrent.impl.ExecutionContextImpl$$anon$1.execute(ExecutionContextImpl.scala:133) at scala.concurrent.impl.CallbackRunnable.executeWithValue(Promise.scala:40) at scala.concurrent.impl.Promise$DefaultPromise.scala$concurrent$impl$Promise$DefaultPromise$$dispatchOrAddCallback(Promise.scala:280) at scala.concurrent.impl.Promise$DefaultPromise.onComplete(Promise.scala:270) at scala.concurrent.Future$class.recover(Future.scala:324) at scala.concurrent.impl.Promise$DefaultPromise.recover(Promise.scala:153) at org.apache.spark.rpc.akka.AkkaRpcEndpointRef.ask(AkkaRpcEnv.scala:319) at org.apache.spark.rpc.RpcEndpointRef.askWithRetry(RpcEndpointRef.scala:100) at org.apache.spark.rpc.RpcEndpointRef.askWithRetry(RpcEndpointRef.scala:77)
  • 当结果集出现数据倾斜,有些数据块大于2G时,同时使用kryo进行序列化时会报NegativeArraySizeException错误。日志信息如下:16/02/16 16:55:13 WARN TaskSetManager: Lost task 750.0 in stage 66.0 (TID 33887, datasight-192): com.esotericsoftware.kryo.KryoException: java.lang.NegativeArraySizeException Serialization trace: values (org.apache.spark.sql.catalyst.expressions.GenericRowWithSchema) at com.esotericsoftware.kryo.serializers.FieldSerializer$ObjectField.write(FieldSerializer.java:585) at com.esotericsoftware.kryo.serializers.FieldSerializer.write(FieldSerializer.java:213) at com.esotericsoftware.kryo.Kryo.writeClassAndObject(Kryo.java:568) at com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.write(DefaultArraySerializers.java:318) at com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.write(DefaultArraySerializers.java:293) at com.esotericsoftware.kryo.Kryo.writeClassAndObject(Kryo.java:568) at org.apache.spark.serializer.KryoSerializerInstance.serialize(KryoSerializer.scala:260) at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:240) 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) Caused by: java.lang.NegativeArraySizeException at com.esotericsoftware.kryo.util.IdentityObjectIntMap.resize(IdentityObjectIntMap.java:409) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.putStash(IdentityObjectIntMap.java:227) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.push(IdentityObjectIntMap.java:221) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.put(IdentityObjectIntMap.java:117) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.putStash(IdentityObjectIntMap.java:228) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.push(IdentityObjectIntMap.java:221) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.put(IdentityObjectIntMap.java:117) at com.esotericsoftware.kryo.util.MapReferenceResolver.addWrittenObject(MapReferenceResolver.java:23) at com.esotericsoftware.kryo.Kryo.writeReferenceOrNull(Kryo.java:598)

可能原因

  • Driver端OOM 把结果收集到Driver端并打印主要有两步,第一步:使用一个数组存储从各节点收集过来的结果,第二步转换成可打印的格式再打印到屏幕上。结果集在内存中是以java对象形式存在的,内存占用比较大,在转化格式的过程中还会生成很多中间数组,使得driver的内存耗费非常大,很容易出现OOM错误。
  • kryo序列化报NegativeArraySizeException错误 Spark对kryo一次序列化的数据大小进行了限制,最多一次序列化2G数据,超过这个限制就会报如上错误。

定位思路

无。

处理步骤

当出现如上问题时,建议可采用如下方法进行调整。

  • 结果集很大时,不要把结果集拿到driver端,建议将结果集落到磁盘中,避免出现OOM错误。
  • 如果已通过上述操作规避OOM错误,那么NegativeArraySizeException错误也不会出现。如果用户不执行上述建议规避错误,您也可以在Spark客户端配置文件“spark-defaults.conf”中设置序列化器spark.serializer = org.apache.spark.serializer.JavaSerializer,来规避出现NegativeArraySizeException错误。
作者 east
bug清单 2月 27,2021

Driver端返回大量结果数据时出现内存不足错误

Driver端返回大量结果数据时出现内存不足错误

现象描述

利用JDBCServer应用,在客户端执行SQL语句。Driver异常退出,在JDBCServer日志中报错信息如下:

2015-11-24 18:29:33,393 ERROR [org.apache.spark.util.Utils] Uncaught exception in thread task-result-getter-3
java.lang.OutOfMemoryError: Java heap space
    at java.io.ObjectInputStream$HandleTable.grow(ObjectInputStream.java:3469)
    at java.io.ObjectInputStream$HandleTable.assign(ObjectInputStream.java:3275)
    at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1674)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1345)
    at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1993)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1918)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
    at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1707)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1345)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
    at org.apache.spark.serializer.JavaDeserializationStream.readObject(JavaSerializer.scala:72)
    at org.apache.spark.serializer.JavaSerializerInstance.deserialize(JavaSerializer.scala:92)
    at org.apache.spark.scheduler.DirectTaskResult.value(TaskResult.scala:97)
    at org.apache.spark.scheduler.TaskResultGetter$$anon$2$$anonfun$run$1.apply$mcV$sp(TaskResultGetter.scala:60)
    at org.apache.spark.scheduler.TaskResultGetter$$anon$2$$anonfun$run$1.apply(TaskResultGetter.scala:51)
    at org.apache.spark.scheduler.TaskResultGetter$$anon$2$$anonfun$run$1.apply(TaskResultGetter.scala:51)
    at org.apache.spark.util.Utils$.logUncaughtExceptions(Utils.scala:1701)
    at org.apache.spark.scheduler.TaskResultGetter$$anon$2.run(TaskResultGetter.scala:50)
    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)

客户端的错误信息如图1:

图1 客户端报的错误


可能原因

分析日志可知,当运行“task-result-getter-3”线程时出现“Out-of-Memory”错误,即表示Driver端获取数据时出现内存不足,导致JDBCServer服务异常。

由于SQL查询的结果数据会返回Driver端,当查询结果数据较大时,会有大量数据返回到Driver。

返回数据的大小的上限由“spark.driver.maxResultSize”配置项控制,当返回结果数据量超过spark.driver.maxResultSize时,Job会抛出异常终止,但不会导致JDBCServer服务异常。在这个问题中,通过查看配置项可知,Driver端的内存为1GB,“spark.driver.maxResultSize”也是1GB,由于Driver进程中还有其他对象占用部分内存,所以在获取的数据量还没有达到“spark.driver.maxResultSize”时,Driver进程内存已经超过1GB从而发生内存溢出,导致JDBCServer服务异常退出。

定位思路

无。

处理步骤

出现该问题,可以通过两种方法修改:增加driver端的内存;控制返回driver端数据的大小。

  1. 根据具体的应用,修改driver端的内存大小,设置方法有如下两种:
    • 在CLASSPATH的“spark-defaults.conf”文件中添加spark.driver.memory 20g。
    • 在启动Spark应用时,命令行中添加:–driver-memory 20g。
  2. 为了减少Driver端出现out-of-memory的错误,您可以适当限制driver端的数据量使其在客户端即报错。 spark.driver.maxResultSize=256m 说明: 建议该配置项的值小于driver端的内存。
  3. 重新运行Spark应用,如上配置即生效。

参考信息

参考官网http://spark.apache.org/docs/latest/configuration.html,对“spark.driver.maxResultSize”配置项的介绍。

作者 east
bug清单 2月 27,2021

Yarn不接受任务的问题

Yarn不接受任务的问题

现象描述

提交Spark任务时,报如下错误。

Exception in thread "main" org.apache.spark.SparkException: Yarn application already ended,might be killed or not able to launch application master.
at org.apache.spark.scheduler.cluster.YarnClientSchedulerBackend.waitForApp(YarnClientSchedulerBackend.scala:111)
at org.apache.spark.scheduler.cluster.YarnClientSchedulerBackend.start(YarnClientSchedulerBackend.scala:87)
at org.apache.spark.scheduler.TaskSchedulerImpl.start(TaskSchedulerImpl.scala:141)
at org.apache.spark.SparkContext.<init>(SparkContext.scala:323)
at org.apache.spark.examples.SparkPi$.main(SparkPi.scala:28)
at org.apache.spark.examples.SparkPi.main(SparkPi.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.spark.deploy.SparkSubmit$.launch(SparkSubmit.scala:332)
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:79)
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)

可能原因

Yarn出现问题,不能支持Spark on Yarn。

定位思路

无。

处理步骤

建议观察Application Master的Web UI报错信息,并联系Yarn相关人员定位。

作者 east
bug清单 2月 27,2021

Spark出现Address already in use: Service ‘SparkUI’ failed after 16 retries!异常

出现Address already in use: Service ‘SparkUI’ failed after 16 retries!异常

现象描述

提交任务时,出现以下错误。此现象多发生在同时有多个任务提交的情况下。

2014-09-17 15:27:04,597 INFO [main] Successfully started service 'HTTP file server' on port 23503. org.apache.spark.Logging$class.logInfo(Logging.scala:59)
2014-09-17 15:27:04,875 WARN [main] Service 'SparkUI' could not bind on port 23000. Attempting port 23001. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:04,942 WARN [main] Service 'SparkUI' could not bind on port 23001. Attempting port 23002. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,003 WARN [main] Service 'SparkUI' could not bind on port 23002. Attempting port 23003. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,086 WARN [main] Service 'SparkUI' could not bind on port 23003. Attempting port 23004. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,147 WARN [main] Service 'SparkUI' could not bind on port 23004. Attempting port 23005. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,213 WARN [main] Service 'SparkUI' could not bind on port 23005. Attempting port 23006. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,275 WARN [main] Service 'SparkUI' could not bind on port 23006. Attempting port 23007. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,336 WARN [main] Service 'SparkUI' could not bind on port 23007. Attempting port 23008. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,396 WARN [main] Service 'SparkUI' could not bind on port 23008. Attempting port 23009. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,461 WARN [main] Service 'SparkUI' could not bind on port 23009. Attempting port 23010. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,523 WARN [main] Service 'SparkUI' could not bind on port 23010. Attempting port 23011. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,586 WARN [main] Service 'SparkUI' could not bind on port 23011. Attempting port 23012. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,644 WARN [main] Service 'SparkUI' could not bind on port 23012. Attempting port 23013. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,704 WARN [main] Service 'SparkUI' could not bind on port 23013. Attempting port 23014. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,763 WARN [main] Service 'SparkUI' could not bind on port 23014. Attempting port 23015. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,825 WARN [main] Service 'SparkUI' could not bind on port 23015. Attempting port 23016. org.apache.spark.Logging$class.logWarning(Logging.scala:71)
2014-09-17 15:27:05,887 ERROR [main] Failed to bind SparkUI org.apache.spark.Logging$class.logError(Logging.scala:96)
java.net.BindException: Address already in use: Service 'SparkUI' failed after 16 retries!
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:187)
at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:316)
at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:265)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.Server.doStart(Server.java:293)
¡­¡­

可能原因

每一个Spark任务都会起一个Driver端口,即SparkUI,默认为23000,如果被占用则随机选取端口重试,默认会重试16次。16次重试都失败后,会放弃任务的运行。

定位思路

使用jps命令查看当前节点上提交的任务数量,如果当前节点的任务数超过了16个,就会造成这样的错误。

处理步骤

使用以下步骤中的任何一个可以解决。

  • 初始化SparkConf时,添加conf.set(“spark.port.maxRetries”,“100”)语句
  • 使用spark-submit提交任务时,在命令行中添加 –conf spark.port.maxRetries=100
  • 在spark-defaults.conf中添加spark.port.maxRetries 100

可以将100替换为任何想要的数字,数字越大,允许同时运行的任务越多。

作者 east
bug清单 2月 27,2021

Spark任务挂起,报Initial job has not accepted any resources异常

任务挂起,报Initial job has not accepted any resources异常

现象描述

在客户端使用yarn-client模式提交任务时,任务不结束,循环报”Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient memory”字样的警告。

可能原因

使用yarn-client模式运行任务时,Spark应用程序的Driver运行在客户端节点上,运行任务的过程中会和集群内Yarn进行通信。该问题可能的原因有:

  • 检查Spark的客户端是否在Yarn所在节点的主机列表中。若不在,则会解析错误,从而造成job不能被初始化的假象。
  • 检查executor memory是否配置太大,导致NodeManager提供的内存不足以启动一个container。

定位思路

  1. 查看集群内每台节点中的“/etc/hosts”文件中是否加入了客户端节点的IP和主机名。如果“/etc/hosts”文件未加入,则修改文件,重试跑应用。
  2. 若“/etc/hosts”加入了客户端节点的IP和主机名后,该问题还存在时,查看Executor端对应的进程CoarseGrainedExecutorBackend是否存在。如果不存在,可能是由于executor memory配置太大导致的。

处理步骤

  1. 在集群内部署Yarn的每台节点的“/etc/hosts”中按照格式加入客户端节点的IP和主机名。
  2. 适当减少executor memory的大小。根据Yarn的可用资源的大小,适当配置executor memory。
作者 east
bug清单 2月 27,2021

出现Not attempting to re-login since the last re-login was attempted less than 600 seconds before异常

出现Not attempting to re-login since the last re-login was attempted less than 600 seconds before异常

现象描述

安全模式下客户端提交代码时,Driver端日志报错如下。

14/09/20 15:29:31 INFO SparkUI: Started SparkUI at http://linux-18:23000
14/09/20 15:29:31 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
14/09/20 15:29:35 WARN UserGroupInformation: Not attempting to re-login since the last re-login was attempted less than 600 seconds before.
14/09/20 15:29:38 WARN UserGroupInformation: Not attempting to re-login since the last re-login was attempted less than 600 seconds before.
14/09/20 15:29:43 WARN UserGroupInformation: Not attempting to re-login since the last re-login was attempted less than 600 seconds before.
14/09/20 15:29:46 WARN UserGroupInformation: Not attempting to re-login since the last re-login was attempted less than 600 seconds before.

或者报如下错误:

Caused by: GSSException: No valid credentials provided (Mechanism level: Clock skew too great (37))
        at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:770)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
        at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:192)
        ... 80 more
Caused by: KrbException: Clock skew too great (37)
        at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:88)
        at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:87)
        at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:259)
        at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:270)
        at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:302)
        at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:120)
        at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:458)
        at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:693)
        ... 83 more

可能原因

Kerberos认证时会对客户端节点和服务端节点上的时间进行认证,如果时间差超过一定阈值(默认为5分钟),则拒绝客户端的连接。

定位思路

使用date命令分别查看客户端以及服务端的日期及时间,如果两者相差5分钟以上,则为时间不同步引起的问题。

处理步骤

  1. 在客户端安装ntp服务进行时间同步。
  2. 手动修改客户端上的时间,使之与服务端一致。
作者 east
bug清单 2月 27,2021

使用Snappy压缩时出现java.lang.UnsatisfiedLinkError: org.apache.hadoop.util.NativeCodeLoader.buildSupportsSnappy()Z的问题

使用Snappy压缩时出现java.lang.UnsatisfiedLinkError: org.apache.hadoop.util.NativeCodeLoader.buildSupportsSnappy()Z的问题

现象描述

当应用程序中使用Snappy压缩时,报出UnsatisfiedLinkError,如下:

14/09/18 20:59:50 WARN TaskSetManager: Lost task 0.0 in stage 1.0 (TID 0, vm-183): java.lang.UnsatisfiedLinkError: org.apache.hadoop.util.NativeCodeLoader.buildSupportsSnappy()Z
org.apache.hadoop.util.NativeCodeLoader.buildSupportsSnappy(Native Method)
org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:63)
org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:190)
org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:176)
org.apache.hadoop.io.SequenceFile$Reader.init(SequenceFile.java:1915)
org.apache.hadoop.io.SequenceFile$Reader.initialize(SequenceFile.java:1810)
org.apache.hadoop.io.SequenceFile$Reader.<init>(SequenceFile.java:1759)
com.spark.common.format.ProtobufFileInputFormat$ProtobufSequenceFileRecordReader.initialize(ProtobufFileInputFormat.java:76)
org.apache.spark.rdd.NewHadoopRDD$$anon$1.<init>(NewHadoopRDD.scala:117)
org.apache.spark.rdd.NewHadoopRDD.compute(NewHadoopRDD.scala:103)
org.apache.spark.rdd.NewHadoopRDD.compute(NewHadoopRDD.scala:65)
org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:262)
org.apache.spark.rdd.RDD.iterator(RDD.scala:229)
org.apache.spark.rdd.UnionRDD.compute(UnionRDD.scala:86)
……….

或者报如下错误:

Error: org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 1.0 failed 4 times, 
most recent failure: Lost task 0.3 in stage 1.0 (TID 7, node3): java.lang.RuntimeException: native snappy library not available: this version of libhadoop was built without snappy support.
         at org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
         at org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
         at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
         at org.apache.hadoop.io.SequenceFile$Reader.init(SequenceFile.java:1918)
         at org.apache.hadoop.io.SequenceFile$Reader.initialize(SequenceFile.java:1813)
         at org.apache.hadoop.io.SequenceFile$Reader.<init>(SequenceFile.java:1762)
         at org.apache.hadoop.io.SequenceFile$Reader.<init>(SequenceFile.java:1776)
         at org.apache.hadoop.mapred.SequenceFileRecordReader.<init>(SequenceFileRecordReader.java:49)
         at org.apache.hadoop.mapred.SequenceFileInputFormat.getRecordReader(SequenceFileInputFormat.java:64)
         at org.apache.spark.rdd.HadoopRDD$$anon$1.<init>(HadoopRDD.scala:239)
         at org.apache.spark.rdd.HadoopRDD.compute(HadoopRDD.scala:216)
         at org.apache.spark.rdd.HadoopRDD.compute(HadoopRDD.scala:101)
         at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:277)
         at org.apache.spark.rdd.RDD.iterator(RDD.scala:244)
         at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:35)
.........                 

可能原因

Spark使用Snappy时,检查是否有native的方法可供调用,结果是没有。

定位思路

Spark依赖HDFS上的数据,计算时依赖YARN。应用程序中使用Snappy压缩,很可能是找不到Snappy的压缩代码。

处理步骤

  1. 进入Spark客户端的“$Spark_Client/conf/spark-defaults.conf”配置文件。
  2. 将spark.executor.extraJavaOptions和spark.driver.extraJavaOptions参数中加入如下参数值。 spark.executor.extraLibraryPath= -Djava.library.path=$HADOOP_HOME/lib/native spark.yarn.cluster.driver.extraLibraryPath= -Djava.library.path=$HADOOP_HOME/lib/native spark.driver.extraLibraryPath= -Djava.library.path=$HADOOP_HOME/lib/native 说明:
    • java.library.path的值对应的是实际环境中的路径。
    • spark.executor.extraJavaOptions和spark.driver.extraJavaOptions参数的等号后面需加空格。

参考信息

无。

作者 east
bug清单, flume 2月 20,2021

Flume Spooling Directory Source 采集NullPointerException

采用flume的Spooling Directory Source,突然遇到下面的错误

(org.apache.flume.source.SpoolDirectoryExtSource2$SpoolDirectoryRunnable.run:277)  - FATAL: Spool Directory source source1: { spoolDir: /home/work/local/log }: Uncaught exception in SpoolDirectorySource thread. Restart or reconfigure Flume to continue processing.
java.lang.NullPointerException
    at org.apache.avro.io.ResolvingDecoder.readLong(ResolvingDecoder.java:159)
    at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:157)
    at org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:177)
    at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:148)
    at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:139)
    at org.apache.avro.file.DataFileStream.next(DataFileStream.java:233)
    at org.apache.flume.serialization.DurablePositionTracker.initReader(DurablePositionTracker.java:171)
    at org.apache.flume.serialization.DurablePositionTracker.<init>(DurablePositionTracker.java:158)
    at org.apache.flume.serialization.DurablePositionTracker.getInstance(DurablePositionTracker.java:76)
    at org.apache.flume.client.avro.ReliableSpoolingFileEventExtReader2.openFile(ReliableSpoolingFileEventExtReader2.java:561)
    at org.apache.flume.client.avro.ReliableSpoolingFileEventExtReader2.getNextFile(ReliableSpoolingFileEventExtReader2.java:511)
    at org.apache.flume.client.avro.ReliableSpoolingFileEventExtReader2.readEvents(ReliableSpoolingFileEventExtReader2.java:264)
    at org.apache.flume.source.SpoolDirectoryExtSource2$SpoolDirectoryRunnable.run(SpoolDirectoryExtSource2.java:252)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

重启flume 后发现问题依旧。试验把flume 采集的日志放到新目录,重启flume采集新目录发现没问题了。看来是旧目录/home/work/local/log 有文件变动造成的。

例如 有.flumespool隐藏目录,该目录下有文件.flumespool-main.meta隐藏文件,用来记录flume读取文件的位置,发现该记录停止在flume出问题的时间。再查看其它正常运行的机器的相同路径及文件,并没有发现该文件,于是将该文件移到其它目录下,重启flume,此时发现flume成功运行!

作者 east
bug清单, python 2月 15,2021

python3解决解决Please use the NLTK Downloader to obtain the resource

运行环境是windows,python3,运行python程序出现下面的错误:

  Please use the NLTK Downloader to obtain the resource:

  [31m>>> import nltk
  >>> nltk.download(‘stopwords’)
  [0m
  Searched in:
    – ‘C:\\Users\\99386/nltk_data’
    – ‘C:\\nltk_data’
    – ‘D:\\nltk_data’
    – ‘E:\\nltk_data’
    – ‘F:\\Program Files\\Python\\Python36\\nltk_data’
    – ‘F:\\Program Files\\Python\\Python36\\lib\\nltk_data’
    – ‘C:\\Users\\99386\\AppData\\Roaming\\nltk_data’

>>>python

>>> import nltk
>>> nltk.download(‘punkt’)

按照上面的命令会安装失败。要采用下面变通的方式:

接下来我们去https://github.com/nltk/nltk_data下载我们需要的数据。

只需下载正数第二个“packages”文件夹即可。把packages文件夹下的所有子文件夹拷贝至上面报错一个路径,例如F:\\Program Files\\Python\\Python36\\nltk_data 。请注意,不要把packages拷过去,而是packages的子文件夹。还有注意包含子文件夹,要把有些压缩包解压,例如把tokenizers下的punkt.zip解压(注意不要多了一层嵌套)。这时运行python程序可以看到原来的问题解决了。

作者 east

上一 1 … 3 4 5 … 7 下一个

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

标签

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

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 如何在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工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?

文章归档

  • 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)
  • 大数据开发 (493)
    • 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)
    • 运维 (35)
      • 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)
  • 未分类 (7)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

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

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