java.lang.OutOfMemoryError: пространство кучи Java с использованием Docker

Итак, я запускаю следующее локально (автономно):

~/spark-2.1.0-bin-hadoop2.7/bin/spark-submit --py-files afile.py run_script.py 

И я получил следующую ошибку:

java.lang.OutOfMemoryError: Java heap space

Чтобы обойти это, я запускаю следующее:

~/spark-2.1.0-bin-hadoop2.7/bin/spark-submit --driver-memory 6G --executor-memory 1G --py-files afile.py run_script.py

и скрипт работает нормально.

Теперь я использую следующую сборку докера для Spark и запускаю следующее:

docker-compose up
docker exec app_master_1 bin/spark-submit --driver-memory 6G --executor-memory 1G --py-files afile.py run_script.py

В этом случае я все еще получаю сообщение об ошибке:

2018-06-13 21:43:16 WARN  TaskSetManager:66 - Lost task 0.0 in stage 3.0 (TID 9, 172.17.0.3, executor 0): java.lang.OutOfMemoryError: Java heap space
at org.apache.spark.sql.catalyst.expressions.codegen.BufferHolder.grow(BufferHolder.java:77)
at org.apache.spark.sql.catalyst.expressions.codegen.UnsafeRowWriter.write(UnsafeRowWriter.java:219)
at org.apache.spark.sql.execution.datasources.text.TextFileFormat$$anonfun$readToUnsafeMem$1$$anonfun$apply$4.apply(TextFileFormat.scala:143)
at org.apache.spark.sql.execution.datasources.text.TextFileFormat$$anonfun$readToUnsafeMem$1$$anonfun$apply$4.apply(TextFileFormat.scala:140)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:409)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:409)
at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.next(FileScanRDD.scala:109)
at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage1.processNext(Unknown Source)
at org.apache.spark.sql.execution.BufferedRowIterator.hasNext(BufferedRowIterator.java:43)
at org.apache.spark.sql.execution.WholeStageCodegenExec$$anonfun$10$$anon$1.hasNext(WholeStageCodegenExec.scala:614)
at scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:408)
at scala.collection.Iterator$$anon$12.hasNext(Iterator.scala:439)
at scala.collection.Iterator$class.foreach(Iterator.scala:893)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1336)
at scala.collection.TraversableOnce$class.foldLeft(TraversableOnce.scala:157)
at scala.collection.AbstractIterator.foldLeft(Iterator.scala:1336)
at scala.collection.TraversableOnce$class.fold(TraversableOnce.scala:212)
at scala.collection.AbstractIterator.fold(Iterator.scala:1336)
at org.apache.spark.rdd.RDD$$anonfun$fold$1$$anonfun$19.apply(RDD.scala:1090)
at org.apache.spark.rdd.RDD$$anonfun$fold$1$$anonfun$19.apply(RDD.scala:1090)
at org.apache.spark.SparkContext$$anonfun$33.apply(SparkContext.scala:2123)
at org.apache.spark.SparkContext$$anonfun$33.apply(SparkContext.scala:2123)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:87)
at org.apache.spark.scheduler.Task.run(Task.scala:109)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:345)
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:748)

и где-то позже:

2018-06-13 21:43:17 ERROR TaskSchedulerImpl:70 - Lost executor 0 on 172.17.0.3: Remote RPC client disassociated. Likely due to containers exceeding thresholds, or network issues. Check driver logs for WARN messages

Насколько я понимаю, несмотря на то, что написано, что в executor 0 недостаточно памяти, мне нужно увеличить память драйвера, так как он автономный, верно??

Любая идея, почему это происходит и как обойти это?

изменить

Ошибка возникает, когда я пытаюсь использовать sqlCont.read.json(json_path), где файл даже недостаточно велик.


person Mpizos Dimitris    schedule 13.06.2018    source источник
comment
Можете ли вы поделиться полной трассировкой стека? У вас несколько контейнеров? где вы получаете эту ошибку?   -  person Kaushal    schedule 13.06.2018
comment
@Kaushal Я немного обновил ответ. Я просто использую docker-compose ссылки, которая создает 2 контейнера: один главный и один рабочий.   -  person Mpizos Dimitris    schedule 14.06.2018


Ответы (1)


Как вы можете видеть здесь, рабочий узел инициализируется с 1 ГБ памяти в вашем сценарии докера, и вы выполняете команду spark-submit с 1 ГБ памяти для исполнителя, поэтому либо вы уменьшаете память исполнителя, либо увеличиваете рабочую память при создании контейнера докера.

person Kaushal    schedule 14.06.2018
comment
Я не думаю, что это правильно. SPARK_WORKER_MEMORY определяет -Xmx для рабочей JVM, а JVM-исполнители запускаются отдельно, а их Xmx контролируется --executor-memory, как в посте OP. - person Tim; 11.03.2020
comment
SPARK_WORKER_MEMORY указывает здесь память контейнеров докеров, а не JVM. Executor JVM работает внутри рабочего контейнера, так что в любом случае, если вы увеличили --executor-memory, это не повлияет, потому что у самого контейнера меньше памяти - person Kaushal; 12.03.2020