我正在运行一个处理多组数据点的Spark应用程序;其中一些需要按顺序处理。在为小型数据点(约100)运行应用程序时,一切正常。但在某些情况下,这些套装的大小约为。 10,000个数据点,这些数据点会导致工作程序崩溃,并显示以下堆栈跟踪:
Exception in thread "main" org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 26.0 failed 4 times, most recent failure: Lost task 0.3 in stage 26.0 (TID 36, 10.40.98.10, executor 1): java.io.FileNotFoundException: /tmp/spark-5198d746-6501-4c4d-bb1c-82479d5fd48f/executor-a1d76cc1-a3eb-4147-b73b-29742cfd652d/blockmgr-d2c5371b-1860-4d8b-89ce-0b60a79fa394/3a/temp_shuffle_94d136c9-4dc4-439e-90bc-58b18742011c (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:102)
at org.apache.spark.storage.DiskBlockObjectWriter.open(DiskBlockObjectWriter.scala:115)
at org.apache.spark.storage.DiskBlockObjectWriter.write(DiskBlockObjectWriter.scala:235)
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:335)
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)
我在此错误的多个实例后检查了所有日志文件,但未找到任何其他错误消息。
在互联网上搜索此问题,我发现两个可能的原因似乎不适用于我的情况:
/tmp/
目录中没有读/写权限。
/tmp/
目录没有足够的空间用于随机播放文件(或其他临时Spark文件)。
/tmp/
目录大约有45GB可用,单个数据点(<1KB)中的数据量意味着可能不是这种情况。我一直在为这个问题喋喋不休几个小时,试图找到解决方法和可能的原因。
是什么导致了这个问题?我怎样才能自己确定原因?
答案 0 :(得分:3)
问题原来是工作人员发生堆栈溢出(ha!)。
在预感中,我重写了完全在驱动程序上执行的操作(有效地禁用了Spark功能)。当我运行此代码时,系统仍然崩溃,但现在显示StackOverflowError
。与我之前认为的相反,显然尾递归方法肯定会导致堆栈溢出,就像任何其他形式的递归一样。在重写方法后不再使用递归时,问题就消失了。
堆栈溢出可能不是唯一可以产生原始FileNotFoundException的问题,但是进行临时代码更改会将操作拉到驱动程序似乎是确定问题的实际原因的好方法。