应用程序_（状态：接受）的应用程序报告永远不会结束 Spark 提交（在 YARN 上使用 Spark 1.2.0）

Posted 2023-04-14

技术标签:

【中文标题】应用程序_（状态：接受）的应用程序报告永远不会结束 Spark 提交（在 YARN 上使用 Spark 1.2.0）【英文标题】：Application report for application_ (state: ACCEPTED) never ends for Spark Submit (with Spark 1.2.0 on YARN) 【发布时间】：2015-08-29 23:41:31 【问题描述】：

我正在运行 kinesis plus spark 应用程序 https://spark.apache.org/docs/1.2.0/streaming-kinesis-integration.html

我如下运行

ec2 实例上的命令：

 ./spark/bin/spark-submit --class org.apache.spark.examples.streaming.myclassname --master yarn-cluster --num-executors 2 --driver-memory 1g --executor-memory 1g --executor-cores 1  /home/hadoop/test.jar

我已经在 EMR 上安装了 spark。

EMR details
Master instance group - 1   Running MASTER  m1.medium   
1

Core instance group - 2 Running CORE    m1.medium

我正在低于 INFO 并且它永远不会结束。

15/06/14 11:33:23 INFO yarn.Client: Requesting a new application from cluster with 2 NodeManagers
15/06/14 11:33:23 INFO yarn.Client: Verifying our application has not requested more than the maximum memory capability of the cluster (2048 MB per container)
15/06/14 11:33:23 INFO yarn.Client: Will allocate AM container, with 1408 MB memory including 384 MB overhead
15/06/14 11:33:23 INFO yarn.Client: Setting up container launch context for our AM
15/06/14 11:33:23 INFO yarn.Client: Preparing resources for our AM container
15/06/14 11:33:24 INFO yarn.Client: Uploading resource file:/home/hadoop/.versions/spark-1.3.1.e/lib/spark-assembly-1.3.1-hadoop2.4.0.jar -> hdfs://172.31.13.68:9000/user/hadoop/.sparkStaging/application_1434263747091_0023/spark-assembly-1.3.1-hadoop2.4.0.jar
15/06/14 11:33:29 INFO yarn.Client: Uploading resource file:/home/hadoop/test.jar -> hdfs://172.31.13.68:9000/user/hadoop/.sparkStaging/application_1434263747091_0023/test.jar
15/06/14 11:33:31 INFO yarn.Client: Setting up the launch environment for our AM container
15/06/14 11:33:31 INFO spark.SecurityManager: Changing view acls to: hadoop
15/06/14 11:33:31 INFO spark.SecurityManager: Changing modify acls to: hadoop
15/06/14 11:33:31 INFO spark.SecurityManager: SecurityManager: authentication disabled; ui acls disabled; users with view permissions: Set(hadoop); users with modify permissions: Set(hadoop)
15/06/14 11:33:31 INFO yarn.Client: Submitting application 23 to ResourceManager
15/06/14 11:33:31 INFO impl.YarnClientImpl: Submitted application application_1434263747091_0023
15/06/14 11:33:32 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:32 INFO yarn.Client:
         client token: N/A
         diagnostics: N/A
         ApplicationMaster host: N/A
         ApplicationMaster RPC port: -1
         queue: default
         start time: 1434281611893
         final status: UNDEFINED
         tracking URL: http://172.31.13.68:9046/proxy/application_1434263747091_0023/
         user: hadoop
15/06/14 11:33:33 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:34 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:35 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:36 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:37 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:38 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:39 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:40 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:41 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)

有人可以告诉我为什么它不起作用吗？

【问题讨论】：

Alexei51: "可能删除setMaster("local[*]")" 【参考方案1】：

当多个用户试图同时在我们的集群上运行时，我遇到了这个确切的问题。解决方法是更改调度程序的设置。

在文件/etc/hadoop/conf/capacity-scheduler.xml 中，我们将属性yarn.scheduler.capacity.maximum-am-resource-percent 从0.1 更改为0.5。

更改此设置会增加可分配给应用程序主服务器的资源比例，从而增加可能同时运行的主服务器数量，从而增加可能的并发应用程序的数量。

【讨论】：

只想补充一点，如果您在资源较少的单台机器上运行集群，这是一个非常重要的参数设置我在 HUE 工作，我也有同样的问题。我在哪里可以找到 capacity-scheduler.xml 文件为我工作。现在可以运行多个 Spark 应用程序 @user5227388 sudo find / -name capacity-scheduler.xml【参考方案2】：

在这种情况下我得到了这个错误：

MASTER=yarn（或 yarn-client） spark-submit 在集群外部的计算机上运行，并且没有从集群到它的路由，因为它被路由器隐藏了

container_1453825604297_0001_02_000001 的日志（来自 ResourceManager Web UI）：

16/01/26 08:30:38 INFO yarn.ApplicationMaster：等待 Spark 驱动程序可以访问。 26 年 1 月 1 日 08:31:41 错误 yarn.ApplicationMaster：无法连接到 192.168.1.180:33074 的驱动程序，正在重试... 26 年 1 月 1 日 08:32:44 错误 yarn.ApplicationMaster：无法连接到 192.168.1.180:33074 的驱动程序，正在重试... 16/01/26 08:32:45 错误 yarn.ApplicationMaster：未捕获的异常： org.apache.spark.SparkException：无法连接到驱动程序！在 org.apache.spark.deploy.yarn.ApplicationMaster.waitForSparkDriver(ApplicationMaster.scala:484)

我通过使用纱线集群模式解决它：MASTER=yarn-cluster。

在另一台以类似方式配置的计算机上，但它的 IP 可以从集群访问，yarn-client 和 yarn-cluster 都可以工作。

其他人可能会因为不同的原因遇到此错误，我的观点是检查错误日志（从终端看不到，但在这种情况下是 ResourceManager Web UI）几乎总是有帮助的。

【讨论】：

与您的情况相同的问题。应该是路由表问题。感谢您的解释！【参考方案3】：

我们可以尝试三种方法来解决此问题。

检查计算机上的 spark 进程并将其终止。

做

ps aux | grep spark

使用 spark 进程获取所有进程 id 并杀死它们，例如

sudo kill -9 4567 7865

检查集群上运行的 Spark 应用程序的数量。

要检查这一点，请执行

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

检查应用程序 id，如果它们超过 1 或超过 2，则杀死它们。您的集群不能同时运行超过 2 个 spark 应用程序。我不是 100% 确定这一点，但是如果你在集群上运行两个以上的 spark 应用程序，它就会开始抱怨。所以，杀了他们这样做可以杀死他们：

yarn application -kill application_1496703976885_00567

检查您的 spark 配置参数。例如，如果您在 spark 应用程序上设置了更多的执行程序内存或驱动程序内存或执行程序数量，这也可能导致问题。因此，减少其中任何一个并运行您的 spark 应用程序，这可能会解决它。

【讨论】：

【参考方案4】：

这表明 YARN 无法为您提交的新应用分配资源。尝试减少您要求的容器的资源（请参阅here），或者在不太繁忙的集群上尝试此操作。

要尝试的另一件事是检查 YARN 是否作为服务正常工作：

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

【讨论】：

我必须启动我的 yarn-nodemngr。谢谢！【参考方案5】：

我有一个资源有限的小型集群（每个节点约 3GB）。通过将最小内存分配更改为足够低的数字来解决此问题。

发件人：

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

收件人：

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

【讨论】：

我在 HUE 工作，我也有同样的问题。我必须在哪里更改上面的代码？【参考方案6】：

我使用 CDH 5.4 的设置略有不同。我认为我的设置中出现此问题的原因是由于错误（文件已存在等）而卡住了，因为这发生在我的代码的其他部分出错并尝试修复并再次启动它之后。

我可以通过在 cloudera 管理器中重新启动集群上的所有服务来解决这个问题，所以我同意之前的回答，即这可能是由于分配给错误的资源而您需要回收这些资源能够再次运行，或者以不同的方式分配它们。

例如我的集群有 4 个可用的执行程序。在一个进程的 SparkConf 中，我将 spark.executor.instances 设置为 4。虽然该进程仍在运行，可能由于某种原因挂起，但我使用 spark 启动了另一项工作（以相同方式，或使用 spark-submit）。 executor.instances 设置为 1（“--num-executors 1”，如果使用 spark-submit）。我只有 4 个，而 4 个被分配给较早的进程，所以这个要求 1 个执行者的进程必须排队等候。

【讨论】：

【参考方案7】：

就我而言，我看到一些旧的 spark 进程（由 Ctrl+Z 停止）仍在运行，并且它们的 AppMaster（驱动程序）可能仍在占用内存。因此，新的 AppMaster 的 from new spark 命令可能会无限期地等待 YarnScheduler 注册，因为 spark.driver.memory 无法在各自的核心节点中分配。当最大资源分配为真并且驱动程序设置为使用可用于核心节点的最大资源时，也会发生这种情况。

所以，我发现了所有那些陈旧的 spark 客户端进程并杀死了它们（这可能已经杀死了它们的驱动程序并释放了内存）。

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

之后我看不到这些消息。

【讨论】：

如果你在运行 Yarn，你可以使用 yarn application -kill 。您可以在端口 8088 上检查作业的状态，如果在本地运行，请将浏览器定向到 localhost:8088。当我在本地开发某些东西时，有时我也会运行 Hive 会话或 Zeppelin 作业，我需要在 Spark 作业执行之前先杀死它们。【参考方案8】：

当使用 yarn-cluster 运行时，所有应用程序日志记录和标准输出都将位于指定的 yarn 应用程序 master 中，并且不会出现 spark-submit。同样正在流式传输应用程序通常不会退出。检查 Hadoop 资源管理器 Web 界面并查看 Spark Web ui 和可从 Hadoop ui 获得的日志。

【讨论】：

即使应用程序结束（非流式批处理作业），此问题似乎仍然存在。【参考方案9】：

我在使用 spark 1.4 和 yarn 的本地 hadoop 集群上遇到了同样的问题，试图运行 spark-shell。它有足够的资源。

帮助的是从集群上的交互式 lsf 作业运行相同的东西。所以也许有一些网络限制从头节点运行纱线......

【讨论】：

【参考方案10】：

在一个例子中，我遇到了这个问题，因为我要求的资源太多。这是在一个小型独立集群上。原来的命令是

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

在其他情况下，由于代码的编写方式，我遇到了这个问题。我们在使用它的类中实例化了 spark 上下文，它并没有被关闭。我们通过首先实例化上下文、将其传递给数据并行化的类等来解决问题，然后在调用者类中关闭上下文 (sc.close())。

【讨论】：

--conf spark.yarn.executor.memoryOverhead。没有价值？【参考方案11】：

我在他们的 HDinsight spark 集群中遇到了同样的问题 MS Azure 集群。终于发现问题是集群无法与驱动程序对话。我假设您在提交作业时使用了客户端模式，因为您可以提供此调试日志。

原因是 spark 执行器必须与驱动程序对话，并且 TCP 连接必须是双向的。因此，如果您的驱动程序在无法通过主机名或 IP 访问的 VM（ec2 实例）中运行（您必须在 spark conf 中指定，默认为主机名），您的状态将永远被接受。

【讨论】：

【参考方案12】：

有类似的问题

就像其他答案在这里指出的那样，这是一个资源可用性问题

在我的例子中，我正在执行一个 etl 进程，每次运行的旧数据都会被丢弃。但是，新删除的数据存储在控制用户的/user/myuser/.Trash 文件夹中。查看 Ambari 仪表板，我可以看到整体 HDFS 磁盘使用量接近容量，这导致了资源问题。

所以在这种情况下，使用 -skipTrash 选项到 hadoop fs -rm ... 旧数据文件（否则将占用垃圾中的空间，大致相当于存储在 etl 存储目录中的所有数据的大小（有效地使总使用空间增加一倍）由应用程序引起的资源问题））。

【讨论】：

【参考方案13】：

当我尝试执行 pyspark shell 时，我在 clouera quickstart VM 中遇到了同样的问题。当我在资源管理器中看到作业日志时，我看到了

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

这意味着作业无法连接到 RM（资源管理器），因为默认情况下 pyspark 尝试在 cloudera VM 中以 yarn 模式启动。

pyspark --master local

为我工作。即使启动 RM 也解决了这个问题。

谢谢

【讨论】：

以上是关于应用程序_（状态：接受）的应用程序报告永远不会结束 Spark 提交（在 YARN 上使用 Spark 1.2.0）的主要内容，如果未能解决你的问题，请参考以下文章

MWS 报告不会从“_SUBMITTED_”更新报告请求状态

Muzei 插件卡在永远不会收到 onUpdate() 调用的状态

在 Android Studio 4.1 中扫描文件以建立索引永远不会结束

Java并发-取消与关闭

构建永远不会结束

XCode 中的 Git 状态永远不会从“A”更改