gpt4 book ai didi

apache-spark - Google Cloud Dataproc 配置问题

转载 作者:行者123 更新时间:2023-12-04 11:35:50 24 4
gpt4 key购买 nike

我在运行的一些 Spark LDA 主题建模中遇到了各种问题(主要是看似随机间隔的分离错误),我认为这主要与我的执行程序上的内存分配不足有关。这似乎与有问题的自动集群配置有关。我最近的尝试使用 n1-standard-8 机器(8 核,30GB RAM)作为主节点和工作节点(6 个工作节点,所以总共 48 个内核)。

但是当我看 /etc/spark/conf/spark-defaults.conf我看到这个:

spark.master yarn-client
spark.eventLog.enabled true
spark.eventLog.dir hdfs://cluster-3-m/user/spark/eventlog

# Dynamic allocation on YARN
spark.dynamicAllocation.enabled true
spark.dynamicAllocation.minExecutors 1
spark.dynamicAllocation.initialExecutors 100000
spark.dynamicAllocation.maxExecutors 100000
spark.shuffle.service.enabled true
spark.scheduler.minRegisteredResourcesRatio 0.0

spark.yarn.historyServer.address cluster-3-m:18080
spark.history.fs.logDirectory hdfs://cluster-3-m/user/spark/eventlog

spark.executor.cores 4
spark.executor.memory 9310m
spark.yarn.executor.memoryOverhead 930

# Overkill
spark.yarn.am.memory 9310m
spark.yarn.am.memoryOverhead 930

spark.driver.memory 7556m
spark.driver.maxResultSize 3778m
spark.akka.frameSize 512

# Add ALPN for Bigtable
spark.driver.extraJavaOptions -Xbootclasspath/p:/usr/local/share/google/alpn/alpn-boot-8.1.3.v20150130.jar
spark.executor.extraJavaOptions -Xbootclasspath/p:/usr/local/share/google/alpn/alpn-boot-8.1.3.v20150130.jar

但这些值没有多大意义。为什么只使用 4/8 个执行器核心?并且只有 9.3/30GB RAM?我的印象是所有这些配置都应该自动处理,但即使我尝试手动调整也无济于事。

例如,我尝试使用以下命令启动 shell:
spark-shell --conf spark.executor.cores=8 --conf spark.executor.memory=24g

但后来这失败了
java.lang.IllegalArgumentException: Required executor memory (24576+930 MB) is above the max threshold (22528 MB) of this cluster! Please increase the value of 'yarn.scheduler.maximum-allocation-mb'.

我尝试更改 /etc/hadoop/conf/yarn-site.xml 中的关联值,没有效果。即使我尝试不同的集群设置(例如使用 60+ GB RAM 的执行程序),我最终还是遇到了同样的问题。出于某种原因,最大阈值保持在 22528MB。

我在这里做错了什么,还是谷歌的自动配置有问题?

最佳答案

集群中的默认内存配置存在一些已知问题,其中主机器类型与工作机器类型不同,但在您的情况下,这似乎不是主要问题。

当您看到以下内容时:

spark.executor.cores 4
spark.executor.memory 9310m

这实际上意味着每个工作节点将运行 2 个执行程序,每个执行程序将使用 4 个内核,因此所有 8 个内核确实在每个工作程序上用完。这样,如果我们给 AppMaster 一半的机器,AppMaster 就可以成功打包到一个 executor 旁边。

分配给 NodeManagers 的内存量需要为 NodeManager 守护进程本身留下一些开销,以及其他。其他守护程序服务,例如 DataNode,因此大约 80% 留给 NodeManagers。此外,分配必须是最小 YARN 分配的倍数,因此在取到最接近的分配倍数之后,这就是 n1-standard-8 的 22528MB 的来源。

如果您添加具有 60+ GB RAM 的工作线程,那么只要您使用相同内存大小的主节点,您就会看到更高的最大阈值数。

无论哪种方式,如果您看到 OOM 问题,那么最重要的不是每个执行程序的内存,而是每个任务的内存。如果您在 spark.executor.cores 的同时增加 spark.executor.memory ,那么每个任务的内存实际上并没有增加,因此在这种情况下您不会真正为应用程序逻辑提供更多空间; Spark 将使用 spark.executor.cores 来确定在同一内存空间中运行的并发任务数。

要实际为每个任务获得更多内存,您应该主要尝试:
  • 使用 n1-highmem-* 机器类型
  • 尝试 减少 spark.executor.cores 同时保留 spark.executor.memory 相同
  • 尝试增加 spark.executor.memory 同时保持 spark.executor.cores 相同

  • 如果您执行上面的 (2) 或 (3),那么与尝试占用所有内核的默认配置相比,您确实会让内核处于空闲状态,但这确实是除了转到 highmem 之外每个任务获得更多内存的唯一方法实例。

    关于apache-spark - Google Cloud Dataproc 配置问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34140667/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com