尊敬的 Apache Spark 爱好者们
我最近启动了一个副业项目，目标是将几台 ODROID XU4 计算机变成一个独立的 Spark 集群。
在设置集群后，我遇到了一个似乎特定于异构多处理器的问题。当使用全部 8 个处理器时，Spark 执行器任务在 XU4 上运行非常缓慢。正如我在下面的帖子的评论中提到的那样，原因是 Spark 不会等待已在慢速处理器上启动的执行程序。
一种解决方案是使用更少的执行程序核心并将 CPU 亲和性设置为不使用 LITTLE 处理器。然而，这并不是一个理想的解决方案。
有没有办法让 Spark 等待更长时间以等待来自较慢执行器的反馈？显然等待太久会对性能产生负面影响。然而，利用所有核心的积极影响应该抵消消极影响。
提前感谢您的帮助！
【问题讨论】：
标签： performance scala apache-spark heterogeneous
@Dikei 的回应强调了两个潜在的原因，但事实证明问题不是他所怀疑的。我的设置与@TJVR 相同，结果发现驱动程序缺少执行程序的心跳。为了解决这个问题，我在spark-env.sh 中添加了以下内容：
export SPARK_DAEMON_JAVA_OPTS="-Dspark.worker.timeout=600 -Dspark.akka.timeout=200 -Dspark.shuffle.consolidateFiles=true"
export SPARK_JAVA_OPTS="-Dspark.worker.timeout=600 -Dspark.akka.timeout=200 -Dspark.shuffle.consolidateFiles=true"
这会更改执行器心跳的默认超时。还将 spark.shuffle.consolidateFiles 设置为 true 以提高我的 ext4 文件系统的性能。这些默认值更改使我能够将核心使用量增加到一个以上，并且不会经常丢失执行程序。
【讨论】：
Spark 不会杀死慢速执行器，但会在两种情况下将执行器标记为已死亡：
如果驱动程序有一段时间没有收到心跳信号（默认：120s）：执行器必须定期（默认：10s）发送心跳消息通知驱动程序它还活着。网络问题或较大的 GC 暂停可以阻止这些心跳发生。
执行器因代码异常或 JVM 运行时错误而崩溃，很可能也是因为 GC 暂停。
在我看来，可能是 GC 开销杀死了你的执行器，驱动程序必须在不同的执行器上重做任务。如果是这种情况，您可以尝试将数据拆分为更小的分区，这样每个执行程序一次只能处理更少的数据。
其次，您不应该在未经测试的情况下将spark.speculation 设置为“true”。默认情况下它是“假”是有原因的，我已经看到它在某些情况下弊大于利。
最后，以下假设可能不成立。
然而，利用所有核心的积极影响应该是平衡的 负面影响。
执行速度慢（散乱）可能会导致程序执行得更差，具体取决于工作负载。完全有可能避免慢速内核将提供最佳结果。
【讨论】：