emr-5.4.0 (проблема выделения памяти для исполнителей Spark)
Я создал кластер искры (обучение, таким образом, не создал кластер с высокой памятью-процессором) с 1 главным узлом и 2 ядрами для запуска исполнителей, используя приведенный ниже конфиг
Мастер:Running1m4.large (2 ядра, 8 ГБ) Core:Running2c4.large (2 ядра, 3,5 ГБ) Hive 2.1.1, Pig 0.16.0, Hue 3.11.0, Spark 2.1.0, Sqoop 1.4.6, HBase 1.3 +0,0
Когда запускается pyspark, появляется ошибка ниже. Требуемая память исполнителя (1024+384 МБ) превышает максимальный порог (896 МБ) этого кластера! Пожалуйста, проверьте значения 'yarn.scheduler.maximum-allocation-mb' и / или 'yarn.nodemanager.resource.memory-mb'.
Прежде чем пытаться увеличить конфигурацию yarn-site.xml, хотелось бы узнать, почему EMR принимает ограничение в 896 МБ, если у master 8 ГБ, а у рабочего узла 3,5 ГБ каждый.
А URL-адрес менеджера ресурсов (для http://master-public-dns-name:8088/) показывает 1,75 ГБ, где в качестве памяти для vm используется 8 ГБ. Hbase или другие SWS занимают слишком много памяти?
Если кто-то сталкивался с подобной проблемой, пожалуйста, поделитесь своим пониманием, почему EMR устанавливает низкие значения по умолчанию. Спасибо!
2 ответа
Это на самом деле не свойство EMR, а скорее YARN, который является менеджером ресурсов, работающим на EMR.
Мой личный взгляд на YARN заключается в том, что он действительно создан для управления кластерами, работающими в течение длительного времени и постоянно выполняющими различные задания, которые он должен выполнять одновременно. В этих случаях для YARN имеет смысл назначать только небольшую часть доступной памяти для каждого задания.
К сожалению, когда речь идет о кластерах специального назначения (например, "я просто раскручиваю кластер, запускаю свою работу и снова завершаю работу кластера"), эти значения по умолчанию YARN просто раздражают, и вам нужно настроить кучу вещей по порядку заставить YARN оптимально использовать ваши ресурсы. Но работа на EMR - это то, с чем мы застряли в эти дни, так что с этим нужно жить...
Прежде чем пытаться увеличить конфигурацию yarn-site.xml, хотелось бы узнать, почему EMR принимает ограничение в 896 МБ, если у master 8 ГБ, а у рабочего узла 3,5 ГБ каждый.
Если вы запускаете спарк-задания в режиме кластера пряжи (который вы, вероятно, использовали), исполнители будут работать на ядре, а память мастера не будет использоваться.
Теперь, несмотря на то, что ваш экземпляр CORE EC2 (c4.large) имеет 3,75 ГБ, EMR настраивает YARN, чтобы не использовать всю эту память для запуска контейнеров YARN или искровых исполнителей. Это связано с тем, что вам нужно оставить достаточно памяти для других постоянных демонов (таких как датода HDFS, менеджер узлов YARN, собственные демоны EMR и т. Д. В зависимости от того, какое приложение вы предоставили)
EMR публикует эту конфигурацию YARN по умолчанию, установленную для всех типов экземпляров, на этой странице: http://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hadoop-task-config.html
c4.large
Configuration Option Default Value
mapreduce.map.java.opts -Xmx717m
mapreduce.map.memory.mb 896
yarn.scheduler.maximum-allocation-mb 1792
yarn.nodemanager.resource.memory-mb 1792
Итак, yarn.nodemanager.resource.memory-mb = 1792, что означает, что 1792 МБ - это физическая память, которая будет выделена для контейнеров YARN на этом базовом узле, имеющем 3,75 фактической памяти. Также проверьте spark-defaults.xml, где EMR имеет некоторые значения по умолчанию для памяти искрового исполнителя. Это значения по умолчанию, и, конечно, вы можете изменить их перед запуском кластера с помощью API-настроек EMR. Но имейте в виду, что если вы перепроизводите память для YARN-контейнеров, вы можете остановить некоторые другие процессы.
Учитывая, что важно понимать настройки YARN и то, как SPARK взаимодействует с YARN.
https://hadoop.apache.org/docs/r2.7.2/hadoop-yarn/hadoop-yarn-common/yarn-default.xml http://spark.apache.org/docs/latest/running-on-yarn.html http://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-2/