Spark Job Ошибка после запуска [дубликат]

Местоположение для установки размера кучи памяти (по крайней мере, в искро-1.0.0) находится в conf / spark-env. Соответствующими переменными являются SPARK_EXECUTOR_MEMORY & amp; SPARK_DRIVER_MEMORY. Дополнительные документы содержатся в руководстве по развертыванию

Кроме того, не забудьте скопировать файл конфигурации на все подчиненные узлы.

Вы должны увеличить память драйвера. Думаю, в вашей папке $ SPARK_HOME / conf вы должны найти файл spark-defaults.conf, отредактировать и установить spark.driver.memory 4000m в зависимости от памяти вашего хозяина. Это то, что исправило проблему для меня, и все работает гладко

Чтобы добавить к этому вариант использования, который часто не обсуждается, я буду представлять решение при подаче приложения Spark через spark-submit в локальном режиме.

Согласно gitbook Освоение Apache Spark Яцек Ласковски :

Вы можете запустить Spark в локальном режиме. В этом нераспределенном режиме развертывания с одним JVM Spark генерирует все компоненты исполнения - драйвер, исполнитель, бэкэнд и мастер - в той же JVM. Это единственный режим, когда драйвер используется для выполнения.

Таким образом, если вы испытываете ошибки OOM с heap, достаточно скорректировать driver-memory, а не executor-memory.

Вот пример:

spark-1.6.1/bin/spark-submit
  --class "MyClass"
  --driver-memory 12g
  --master local[*] 
  target/scala-2.10/simple-project_2.10-1.0.jar 

У меня есть несколько советов:

• Если ваши узлы настроены на максимум 6 г для Spark (и немного оставляют для других процессов), используйте 6g, а не 4g, spark.executor.memory=6g. Убедитесь, что вы используете как можно больше памяти, проверяя пользовательский интерфейс (он скажет, сколько мемов вы используете)
• Попробуйте использовать больше разделов, у вас должно быть 2 - 4 на процессор. IME, увеличивающее количество разделов, часто является самым простым способом сделать программу более стабильной (и часто быстрее). Для огромных объемов данных вам может потребоваться более 4-х процессоров, поэтому в некоторых случаях мне пришлось использовать 8000 разделов!
• Уменьшите долю памяти, зарезервированную для кеширования, используя spark.storage.memoryFraction. Если вы не используете cache() или persist в своем коде, это может быть равно 0. По умолчанию это 0,6, что означает, что вы получаете только 0,4 * 4g памяти для своей кучи. IME, уменьшающий память, часто заставляет OOM уходить. ОБНОВЛЕНИЕ: от искры 1.6, по-видимому, нам больше не нужно будет играть с этими значениями, искру определит их автоматически.
• Как и в предыдущем случае, но в произвольной памяти. Если ваша работа не нуждается в большой памяти в случайном порядке, установите ее на более низкое значение (это может привести к переполнению ваших тасований на диск, которые могут иметь катастрофическое влияние на скорость). Иногда, когда это операция в случайном порядке, то есть OOMing, вам нужно сделать обратное, то есть установить ее на что-то большое, например 0,8, или убедиться, что вы разрешаете перетасовку на диск (это значение по умолчанию с 1.0.0).
• Следите за утечками памяти, они часто вызваны случайным закрытием объектов, которые вам не нужны в ваших лямбдах. Способ диагностики заключается в том, чтобы следить за «задачей, сериализованной как XXX байты» в журналах, если XXX больше, чем несколько килобайт или более, чем МБ, может возникнуть утечка памяти. См. https://stackoverflow.com/a/25270600/1586965
• Связано с выше; использовать широковещательные переменные, если вам действительно нужны большие объекты.
• Если вы кешируете большие RDD и можете жертвовать некоторым временем доступа, подумайте о сериализации RDD http://spark.apache.org/docs/latest /tuning.html#serialized-rdd-storage.
• (Дополнительно) Связано с выше, избегайте String и сильно вложенных структур (например, Map и вложенных классов классов ). Если возможно, попробуйте использовать только примитивные типы и индексировать все непримитивы, особенно если вы ожидаете много дубликатов. Выберите WrappedArray по вложенным структурам, когда это возможно. Или даже разверните свою собственную сериализацию - у ВАС будет больше информации о том, как эффективно вернуть свои данные в байты, USE IT!
• (бит взломанный) Снова при кешировании рассмотрите возможность использования Dataset для кэширования ваша структура, поскольку она будет использовать более эффективную сериализацию. Это следует рассматривать как взлом по сравнению с предыдущим пунктом. Построение знаний домена в вашем алгоритме / сериализации может свести к минимуму объем памяти / кеш-пространства на 100x или 1000x, тогда как все Dataset, скорее всего, дадут 2x - 5x в памяти и 10x сжатый (паркет) на диске.

http://spark.apache.org/docs/1.2.1/configuration.html

РЕДАКТИРОВАТЬ: (Так что я могу сделать проще Google). следующая также указывает на эту проблему:

java.lang.OutOfMemoryError : GC overhead limit exceeded

Вы должны настроить параметры настройки offHeap, как показано ниже:

`val spark = SparkSession
     .builder()
     .master("local[*]")
     .config("spark.executor.memory", "70g")
     .config("spark.driver.memory", "50g")
     .config("spark.memory.offHeap.enabled",true)
     .config("spark.memory.offHeap.size","16g")   
     .appName("sampleCodeForReference")
     .getOrCreate()`

Дать память памяти и память исполнительного устройства в соответствии с вашей оперативной памятью. Вы можете увеличить размер offHeap, если вы все еще сталкиваетесь с проблемой OutofMemory.

В широком смысле, искры памяти JVM Executor можно разделить на две части. Spark memory и User memory. Это контролируется свойством spark.memory.fraction - значение находится между 0 и 1. При работе с изображениями или интенсивной обработке памяти в искровых приложениях рассмотрите возможность уменьшения spark.memory.fraction. Это сделает больше памяти доступной для вашей работы приложения. Spark может разливаться, поэтому он будет работать с меньшим объемом памяти.

Вторая часть проблемы - разделение работы. Если возможно, разделите свои данные на более мелкие куски. Для меньших данных, возможно, требуется меньше памяти. Но если это невозможно, вы жертвоприносите на память. Обычно один исполнитель будет запускать несколько ядер. Общая память исполнителей должна быть достаточной для удовлетворения требований к памяти всех параллельных задач. Если увеличение памяти исполнителя не является вариантом, вы можете уменьшить количество ядер на каждого исполнителя, чтобы каждая задача получала больше памяти для работы. Тест с 1 основным исполнителем, который имеет наибольшую возможную память, которую вы можете дать, а затем продолжать увеличивать ядра, пока не найдете лучший подсчет ядра.

Посмотрите на сценарии запуска , там установлен размер кучи Java, похоже, что вы не устанавливаете это перед запуском рабочего Spark.

# Set SPARK_MEM if it isn't already set since we also use it for this process
SPARK_MEM=${SPARK_MEM:-512m}
export SPARK_MEM

# Set JAVA_OPTS to be able to load native libraries and to set heap size
JAVA_OPTS="$OUR_JAVA_OPTS"
JAVA_OPTS="$JAVA_OPTS -Djava.library.path=$SPARK_LIBRARY_PATH"
JAVA_OPTS="$JAVA_OPTS -Xms$SPARK_MEM -Xmx$SPARK_MEM"

Вы можете найти документацию для развертывания скриптов здесь .