Отчет приложения для application_ (состояние: ACCEPTED) никогда не заканчивается для Spark Submit (с Spark 1.2.0 на YARN)

Ответ 1

У меня была эта точная проблема, когда несколько пользователей пытались запустить сразу в нашем кластере. Исправлено изменение настроек планировщика.

В файле /etc/hadoop/conf/capacity-scheduler.xml мы изменили свойство yarn.scheduler.capacity.maximum-am-resource-percent от 0.1 до 0.5.

Изменение этого параметра увеличивает долю ресурсов, которые становятся доступными для назначения мастерам приложений, увеличивая количество мастеров, которые можно запускать сразу, и, следовательно, увеличивая количество возможных одновременных приложений.

Ответ 2

В этой ситуации я получил эту ошибку:

• MASTER = пряжа (или пряжа-клиент)
• spark-submit запускается на компьютере вне кластера, и нет пути от кластера к нему, поскольку он скрыт маршрутизатором

Журналы для container_1453825604297_0001_02_000001 (из веб-интерфейса ResourceManager):

16/01/26 08:30:38 INFO yarn.ApplicationMaster: Waiting for Spark driver to be reachable.
16/01/26 08:31:41 ERROR yarn.ApplicationMaster: Failed to connect to driver at 192.168.1.180:33074, retrying ...
16/01/26 08:32:44 ERROR yarn.ApplicationMaster: Failed to connect to driver at 192.168.1.180:33074, retrying ...
16/01/26 08:32:45 ERROR yarn.ApplicationMaster: Uncaught exception: 
org.apache.spark.SparkException: Failed to connect to driver!
    at org.apache.spark.deploy.yarn.ApplicationMaster.waitForSparkDriver(ApplicationMaster.scala:484) 

Я обходлю это, используя режим кладки пряжи: MASTER = нить-кластер.

На другом компьютере, который настроен аналогичным образом, но IP доступен из кластера, работают как пряжа-клиент, так и пряжи.

Другие могут столкнуться с этой ошибкой по разным причинам, и моя точка зрения заключается в том, что проверка журналов ошибок (не видно из терминала, но веб-интерфейс ResourceManager ResourceManager в этом случае) почти всегда помогает.

Ответ 3

Это говорит о том, что YARN не может назначать ресурсы для нового приложения, которое вы отправляете. Попытайтесь уменьшить ресурсы для запрашиваемого контейнера (см. здесь) или попробуйте сделать это в менее загруженном кластере.

Еще одна вещь, которую нужно попробовать - проверить, правильно ли работает YARN в качестве службы:

sudo service hadoop-yarn-nodemanager status
sudo service hadoop-yarn-resourcemanager status

Ответ 4

У меня был небольшой кластер, где ресурсы были ограничены (~ 3 ГБ на node). Решив эту проблему, изменив минимальное распределение памяти на достаточно низкое число.

From:

yarn.scheduler.minimum-allocation-mb: 1g
yarn.scheduler.increment-allocation-mb: 512m

To:

yarn.scheduler.minimum-allocation-mb: 256m
yarn.scheduler.increment-allocation-mb: 256m

Ответ 5

Я немного настроен на использование CDH 5.4. Я думаю, что причиной этой проблемы в моей настройке является то, что вы застряли из-за ошибки (файл уже существует и т.д.), Потому что это происходит после некоторых других ошибок моего кода и пытается исправить и снова выключить его.

Я могу обойти это, перезапустив все службы в кластере в диспетчере cloudera, поэтому я согласен с более ранними ответами, что, вероятно, из-за ресурсов, которые выделяются для чего-то из-за ошибки, и вам нужно вернуть эти ресурсы могут снова запускаться или выделять их по-другому.

например. у моего кластера есть 4 исполнителя. В SparkConf для одного процесса я устанавливал значение spark.executor.instances равным 4. Пока этот процесс все еще работает, по какой-то причине потенциально зависает, я запускаю другое задание (то же самое, или с помощью spark-submit), с искру. executor.instances установлен на 1 ( "--num-executors 1" при использовании spark-submit). У меня только 4, а 4 - для более раннего процесса, поэтому этот запрос, запрашивающий 1 исполнителя, должен ждать в очереди.

Ответ 6

В моем случае я вижу, что некоторые старые искровые процессы (которые останавливаются Ctrl + Z) все еще запущены, а их AppMasters (драйверы), вероятно, все еще занимают память. Таким образом, новый AppMaster из новой команды искры может ждать бесконечно, чтобы зарегистрировать YarnScheduler, поскольку spark.driver.memory не может быть выделен в соответствующих основных узлах. Это также может произойти, когда максимальное распределение ресурсов истинно и если драйвер настроен на использование максимальных ресурсов, доступных для ядра node.

Итак, я идентифицировал все эти процессы, связанные с искровым клиентом, и убил их (что, возможно, убило их Драйверы и освобожденную память).

ps -aux | grep spark

hadoop    3435  1.4  3.0 3984908 473520 pts/1  Tl   Feb17   0:12  .. org.apache.spark.deploy.SparkSubmit --conf spark.driver.memory=1G --class org.apache.spark.examples.SparkPi /usr/lib/spark/lib/spark-examples.jar 10

hadoop   32630  0.9  3.0 3984908 468928 pts/1  Tl   Feb17   0:14 .. org.apache.spark.deploy.SparkSubmit --conf spark.driver.memory=1G --class org.apache.spark.examples.SparkPi /usr/lib/spark/lib/spark-examples.jar 1000

    kill -9 3435 32630

После этого я не вижу эти сообщения.

Ответ 7

В одном случае у меня была эта проблема, потому что я просил слишком много ресурсов. Это было на небольшом отдельном кластере. Первоначальная команда была

spark-submit --driver-memory 4G --executor-memory 7G -class "my.class" --master yarn --deploy-mode cluster --conf spark.yarn.executor.memoryOverhead my.jar

Мне удалось пройти мимо "Принято" и "Бегать", перейдя на

spark-submit --driver-memory 1G --executor-memory 3G -class "my.class" --master yarn --deploy-mode cluster --conf spark.yarn.executor.memoryOverhead my.jar

В других случаях у меня была эта проблема из-за способа написания кода. Мы создали контекст искры внутри класса, где он использовался, и он не закрывался. Мы исправили проблему, сначала создав экземпляр контекста, передав его классу, где распараллеливаются данные и т.д., Затем закрываем контекст (sc.close()) в классе вызывающего.

Ответ 8

Я столкнулся с той же проблемой кластера MS Azure в своем искровом кластере HDinsight.
наконец выяснилось, что проблема не в том, что кластер не смог поговорить с водителем. Я предполагаю, что вы использовали режим клиента при отправке задания, так как вы можете предоставить этот журнал отладки.

причина, по которой исполнители искры должны говорить с программой драйвера, а TCP-соединение должно быть двунаправленным. поэтому, если ваша программа драйвера запущена в виртуальной машине (экземпляр ec2), которая недоступна через имя хоста или IP-адрес (вы должны указывать в параметре spark conf, по умолчанию для имени хоста), ваш статус будет принят навсегда.

Ответ 9

Есть три способа устранить эту проблему.

• Проверьте искровый процесс на вашей машине и убейте его.

Do

ps aux | grep spark

Возьмите весь идентификатор процесса с искровыми процессами и убейте их, например

sudo kill -9 4567 7865

2. Проверьте количество искровых приложений, запущенных на вашем кластере.

Чтобы проверить это, сделайте

yarn application -list

вы получите результат, похожий на этот:

Total number of applications (application-types: [] and states: [SUBMITTED, ACCEPTED, RUNNING]):1
                Application-Id      Application-Name        Application-Type          User       Queue               State         Final-State         Progress                        Tracking-URL
application_1496703976885_00567       ta da                SPARK        cloudera       default             RUNNING           UNDEFINED              20%             http://10.0.52.156:9090

Проверьте идентификатор приложения, если он больше 1 или более 2, убейте их. В то же время ваш кластер не может запускать более двух искровых приложений. Я не уверен на 100%, но на кластере, если вы запускаете более двух искровых приложений, он начнет жаловаться. Итак, убейте их Сделайте это, чтобы убить их:

yarn application -kill application_1496703976885_00567

3. Проверьте параметры конфигурации зажигания. Например, если вы установили большую память исполнителей или память драйвера или количество исполнителей на искровое приложение, которое также может вызвать проблему. Итак, уменьшите любой из них и запустите свое искровое приложение, которое может его решить.

Ответ 10

При запуске с помощью нитевого кластера все протоколирование приложений и stdout будут расположены в назначенной мастер-схеме нити и не будут отображаться в качестве источника-источника. Также потоковое приложение обычно не выходит. Проверьте веб-интерфейс менеджера ресурсов Hadoop и посмотрите веб-страницы и журналы Spark, которые будут доступны на Hadoop ui.

Ответ 11

У меня была та же проблема на локальном кластере с плавкой 1.4 и пряжей, пытаясь запустить искровую оболочку. У этого было более чем достаточно ресурсов.

То, что помогло, было выполнено то же самое из интерактивного задания lsf в кластере. Так что, возможно, были некоторые ограничения сети для запуска пряжи из головы node...

Ответ 12

Я столкнулся с той же проблемой в быстром старте VM clouera, когда пытался выполнить оболочку pyspark. Я вижу журналы работы в resourcemanager, я вижу

17/02/18 22:20:53 ERROR yarn.ApplicationMaster: Failed to connect to driver at RM IP. 

Это означает, что задание не может подключиться к RM (менеджер ресурсов), поскольку по умолчанию pyspark пытается запустить в режиме пряжи в cloudera VM.

pyspark --master local 

работал у меня. Даже запуск РМ разрешил проблему.

Спасибо