当我在spark中搜索与内存相关的问题时，我遇到了this article，它建议减少每个执行器的内核数量，但在同一篇文章中，它提到我们使用以下公式获得了执行器的数量（（每个节点的内核数 * 节点总数）/每个执行器的内核数），因此如果我们减少每个执行器的内核数，那么我们如何通过减少每个执行器的内核数量来解决这个问题呢？
当我在spark中搜索与内存相关的问题时，我遇到了this article，它建议减少每个执行器的内核数量，但在同一篇文章中，它提到我们使用以下公式获得了执行器的数量（（每个节点的内核数 * 节点总数）/每个执行器的内核数），因此如果我们减少每个执行器的内核数，那么我们如何通过减少每个执行器的内核数量来解决这个问题呢？
1条答案
按热度按时间n3schb8v1#
实际上本文中提到的优化是纯理论的：
首先，他隐含地假设，即使将每个执行器的核心数从5减少到4，执行器的数量也不会改变。因为通常情况下，当我们更改每个执行器的核心数时，执行器的数量可能会改变，因为nb执行器= nb核心/执行器核心数，而核心数在群集中是固定的
但是在他的情况下，执行器的nb总是3，因此每个执行器的RAM保持为36 GB，这允许每个核更多的RAM（每个核的RAM =每个执行器的RAM/每个执行器的核）36 GB/4 = 9 GB，其大于36 GB/ 5 = 7 GB。
其次，他认为任务需要超过7 GB，但少于9 GB，这对我来说是无法预测的。每个任务所需的数据取决于输入数据和数据分布，并不容易控制在一个精确的范围。
我更愿意说，在spark作业期间减少磁盘溢出是优化spark性能的好方法，减少执行器内核是可能减少磁盘溢出的方法之一（但我确信这并不总是有效的方法）