由于java.io.filenotfoundexception:/hadoop/yarn/nm local dir/usercache/root/appcache,google的dataproc上的spark失败/

hfwmuf9z  于 2021-05-29  发布在  Hadoop
关注(0)|答案(2)|浏览(1143)

我已经在dataproc上使用spark/hadoop好几个月了,通过zeppelin和dataproc控制台,但是就在最近,我遇到了以下错误。

Caused by: java.io.FileNotFoundException: /hadoop/yarn/nm-local-dir/usercache/root/appcache/application_1530998908050_0001/blockmgr-9d6a2308-0d52-40f5-8ef3-0abce2083a9c/21/temp_shuffle_3f65e1ca-ba48-4cb0-a2ae-7a81dcdcf466 (No such file or directory)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
at org.apache.spark.storage.DiskBlockObjectWriter.initialize(DiskBlockObjectWriter.scala:103)
at org.apache.spark.storage.DiskBlockObjectWriter.open(DiskBlockObjectWriter.scala:116)
at org.apache.spark.storage.DiskBlockObjectWriter.write(DiskBlockObjectWriter.scala:237)
at org.apache.spark.shuffle.sort.BypassMergeSortShuffleWriter.write(BypassMergeSortShuffleWriter.java:151)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:96)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:53)
at org.apache.spark.scheduler.Task.run(Task.scala:108)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:338)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

首先,我在齐柏林飞艇笔记本上发现了这种错误,并认为这是齐柏林飞艇的问题。然而,这个错误似乎是随机发生的。我怀疑这与spark的一个工作人员不能在那条路上写字有关。所以,有人建议我在google上删除每个spark worker的/hadoop/yarn/nm local dir/usercache/下的文件,并检查每个worker上是否有可用的磁盘空间。这样做之后,我有时还是会犯这样的错误。我还在dataproc上运行了一个spark作业,也发生了类似的错误。我使用的是dataproc映像版本1.2。
谢谢
皮拉纳特f。

f87krz0w

f87krz0w1#

好 啊。我们在gcp上面临同样的问题,原因是资源抢占。
在gcp中,资源抢占可以通过以下两种策略来实现:,
节点抢占-删除集群中的节点并替换它们
容器抢占-移除Yarn容器。
此设置由您的管理员/开发人员在gcp中完成,以优化集群的成本和资源利用率,特别是在共享集群时。
堆栈跟踪告诉我的是它的节点抢占。此错误是随机发生的,因为有时被抢占的节点是导致应用程序一起失败的驱动程序节点。
您可以在gcp控制台中看到哪些节点是可抢占的。

rqcrx0a6

rqcrx0a62#

以下可能是其他可能的原因:
集群使用抢占工人(他们可以在任何时候被删除),因此他们的工作没有完成,并可能导致不一致的行为。
在spark作业执行期间,节点中存在导致重新启动任务/容器/执行器的调整大小。
内存问题。洗牌操作通常是在内存中完成的,但是如果内存资源被占用,就会溢出到磁盘上。
worker中的磁盘空间已满,这是由于大量的洗牌操作或任何其他在worker中使用磁盘的进程(例如日志)造成的。
终止任务,为失败的尝试腾出空间。
因此,我总结了以下可能的解决方法:
1.-增加工人和大师的记忆,如果你面临记忆问题,这将被丢弃。
2.-更改dataproc的图像版本。
3.-更改集群属性以调整集群,特别是mapreduce和spark。

相关问题