成批缩松作业纱线簇的低性能
aws上的3台机器（32个内核和64 GB内存）
我手动安装了带有hdfs和yarn服务的Hadoop2（没有使用EMR）。
机器#1运行hdfs-(NameNode&SeconderyNameNode)和yarn-(resourcemanager)，在masters文件中定义
问题是，我认为我做错了，因为这项工作需要相当多的时间，大约一个小时，我认为它不是很优化。
我使用以下命令运行flink：
./flink-1.3.0/bin/flink run-yn 2-ys 30-yjm 7000-ytm 8000-m yarn-cluster/home/ubuntu/reports_script-1.0-snapshot.jar
我做错了什么？
共有1个答案
有几件事要注意：
>
每个TaskManager容器的VCore数量的默认值为1。要增加这一点，请使用yarn.containers.vcores参数。除非您使用容器执行器强制容器只使用vcore多个CPU内核，否则它可能不会对作业产生任何影响（只是在YARN UI中看起来很奇怪）。
为TaskManager提供7GB内存意味着它实际上将得到大约5.2GB的JVM堆，因为JVM需要一些“截断”。对于30个插槽来说，5.3GB意味着每个插槽大约有170 MBs的内存。这很有效，但实际上不是很多。
-
我正在使用spark submit执行以下命令： spark submit script\u测试。py—主纱线—部署模式群集spark submit script\u测试。py—主纱线簇—部署模式簇 这工作做得很好。我可以在Spark History Server UI下看到它。但是，我无法在RessourceManager UI（纱线）下看到它。 我感觉我的作业没有发送到集群，但它只在一个节点上
-
我在Thread上运行flink作业，我们使用命令行中的“fink run”将作业提交给Thread，有一天我们在flink作业上出现异常，因为我们没有启用flink重启策略，所以它只是失败了，但最终我们从Thread应用程序列表中发现作业状态为“成功”，我们预期为“失败”。 Flink CLI日志： Flink作业管理器日志： 有谁能帮我理解为什么塞恩说我的Flink工作是“成功的”？
-
我正面临一个问题，当提交一个火花作业罐子在纱。当我用-master yarn-client提交它时，它工作得很好，并给出了我预期的结果 命令如下所示； ./spark-submit--类main.mainclass--主纱--客户端--驱动程序--内存4G--执行器--内存4G--num-执行器4--执行器-核心2 job.jar其他--选项
-
作为Apache Flink的新手，以及流处理框架的一般情况下，我有几个关于它的问题，特别是关于并行性的问题。 首先，这是我的代码： 当我想在集群上运行它时，我运行以下命令： 2.为什么Flink没有为这一步使用所有可能的线程？ 我注意到源、窗口和接收器由不同的从服务器处理，但我仍然希望在集群上并行处理。 我在这篇文章中读到:https://stackoverflow.com/a/32329010
-
我正在AWS EMR集群上使用pyspark3内核运行Jupyterhub。正如我们可能知道的那样，EMR上的Jupyterhub pyspark3使用Livy会话在AWS EMR YARN调度程序上运行工作负载。我的问题是关于火花的配置：执行器内存/内核、驱动程序内存/内核等。 配置中已经有默认配置。Jupyter的json文件： 我们可以改写此配置使用spackMagic： 火花默认值中也有配
-
我用纱线做Flink的工作。对于每个Flink作业，我都会创建一个检查点。 我提交了一份在我的纱线集群中运行的Flink作业。我有一个轮询作业，它检查一个作业是否在纱线上失败并重新启动它。再次提交作业时，纱线会为此Flink作业创建一个新的application\u id。如何配置重新提交的Flink作业以使用重新启动的Flink作业的检查点。 我已经设置了conf的状态。保存点。目录=hdfs: