在配置spark应用程序时，我试图压缩集群中的每一点，但似乎我并没有完全正确地理解每一点。所以我在一个aws emr集群上运行这个应用程序，该集群有1个主节点和2个m3.xlarge类型的核心节点（每个节点有15g ram和4个vcpu）。这意味着在默认情况下，每个节点上为yarn调度的应用程序保留11.25 gb。因此，主节点仅由资源管理器（yarn）使用，这意味着剩余的2个核心节点将用于调度应用程序（因此我们有22.5g用于此目的）。到现在为止，一直都还不错。但我不明白的部分来了。我使用以下参数启动spark应用程序：
--驱动程序内存4g—num executors 4—executor cores 7—executor内存4g
这意味着我的看法（从我发现的信息）是，驱动程序将被分配4g和4个执行者将推出4g每一个。所以粗略估计是5*4=20g（让他们使用21g的预期内存储备），这应该很好，因为我们有22.5g的应用程序。以下是hadoopYarn发布后的ui截图：

我们可以看到，应用程序使用了17.63，但这比预期的21g要少一点，这引发了第一个问题——这里发生了什么？
然后我转到spark ui的executors页面。更大的问题来了：

执行器是3（不是4），分配给它们的内存和驱动程序是2.1g（不是指定的4g）。所以hadoop yarn说使用了17.63g，但是spark说分配了8.4g。那么，这里发生了什么？这是否与容量调度器有关（从文档中我无法得出这个结论）？