我的集群配置如下:-7个节点,每个节点有32个核心和252 GB内存。
纱线配置如下:-
yarn.scheduler.maximum-allocation-mb - 10GB
yarn.scheduler.minimum-allocation-mb - 2GB
yarn.nodemanager.vmem-pmem-ratio - 2.1
yarn.nodemanager.resource.memory-mb - 22GB
yarn.scheduler.maximum-allocation-vcores - 25
yarn.scheduler.minimum-allocation-vcores - 1
yarn.nodemanager.resource.cpu-vcores - 25
map reduce配置如下:-
mapreduce.map.java.opts - -Xmx1638m
mapreduce.map.memory.mb - 2GB
mapreduce.reduce.java.opts - -Xmx3276m
mapreduce.reduce.memory.mb - 4Gb
spark.yarn.driver.memoryOverhead 384
spark.yarn.executor.memoryOverhead 384
在这种情况下,对于纱线调度程序,执行器内存+384最大不能超过10GB。在本例中,9856M+384 MB=10GB,因此它工作正常。现在,一旦spark shell启动,执行程序的总数是124个,而不是请求的175个。每个执行器的spark shell启动日志或spark UI中的存储内存为6.7GB(即10GB的67%)。
spark shell进程的top命令输出如下:-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
8478 hdp66-ss 20 0 13.5g 1.1g 25m S 1.9 0.4 2:11.28
因此虚拟内存为13.5G,物理内存为1.1G
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
5256 hdp66-ss 20 0 13.2g 1.1g 25m S 2.6 0.4 1:25.25
因此虚拟内存为13.2G,物理内存为1.1G
在这种情况下,对于纱线调度程序,执行器内存+384最大不能超过10GB。在本例中,4096M+384 MB=4GB,因此工作正常。现在,一旦spark shell启动,执行程序的总数为200个。在spark shell启动日志或spark UI中,每个执行器的存储内存为2.7GB(即4GB的67%)。
spark shell进程的top命令输出如下:-
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
21518 hdp66-ss 20 0 19.2g 1.4g 25m S 3.9 0.6 2:24.46
Spark几乎总是分配用户为执行程序请求的65%到70%的内存。Spark的这一行为缘于一张Spark JIRA票“spark-12579”。
这个链接指向Apache Spark存储库中的scala文件,该文件用于计算执行器内存等。
if (conf.contains("spark.executor.memory")) {
val executorMemory = conf.getSizeAsBytes("spark.executor.memory")
if (executorMemory < minSystemMemory) {
throw new IllegalArgumentException(s"Executor memory $executorMemory must be at least " +
s"$minSystemMemory. Please increase executor memory using the " +
s"--executor-memory option or spark.executor.memory in Spark configuration.")
}
}
val usableMemory = systemMemory - reservedMemory
val memoryFraction = conf.getDouble("spark.memory.fraction", 0.6)
(usableMemory * memoryFraction).toLong
}
请先用以下条款验证我: 执行器:它的将运行在上。每个节点可以有多个执行器。 核心:它是内的一个线程,运行在上。每个执行器可以有多个内核或线程。 > 当我们提交火花作业时,它意味着什么?我们是否将工作移交给Yarn或resource manager,它将分配资源给集群中的并执行它?它是正确的理解…? 在spark集群中用于提交作业的命令中,有一个设置执行者数量的选项。 那么这些执行器+核的数量将会是
null null 为了进行简单的开发,我使用在独立集群模式下(8个工作者、20个内核、45.3G内存)执行了我的Python代码。现在我想为性能调优设置执行器内存或驱动程序内存。 在Spark文档中,执行器内存的定义是 每个执行程序进程使用的内存量,格式与JVM内存字符串相同(例如512M、2G)。
我正在对YARN上的Spark作业进行一些内存调优,我注意到不同的设置会给出不同的结果,并影响Spark作业运行的结果。但是,我很困惑,不明白为什么会这样,如果有人能给我一些指导和解释,我会很感激。 我将提供一些背景资料和张贴我的问题和描述案例,我已经经历了他们在下面。 我的环境设置如下: 存储器20G,每个节点20个vCore(共3个节点) Hadoop 2.6.0 火花1.4.0 我的代码对R
1)谁能解释一下为什么显示的是31GB而不是60GB。2)还有助于为上述参数设置最佳值。
我有一个大约 100GB 的数据源,我正在尝试使用日期列对其进行分区。 为了避免分区内出现小块,我添加了一个重新分区(5 ),使每个分区内最多有5个文件: 我的问题是,在我分配的30个执行器中,只有5个在实际运行。最后我得到了我想要的东西(每个分区内有5个文件),但由于只有5个执行器在运行,所以执行时间非常长。 你有什么建议可以让我做得更快吗?