如果我理解正确,当reduce任务开始收集其输入shuffle块(来自不同map任务的输出)时,它首先将它们保存在内存中(Q1).当执行器的shuffle-reserved内存量(在内存管理(Q2)更改之前)耗尽时,内存中数据被"溢出"到磁盘.如果spark.shuffle.spill.compress为true,那么内存中的数据将以压缩方式写入磁盘.
我的问题:
问题:我的理解是否正确？
Q1:reduce任务中收集的数据是否始终未压缩？
Q2:如何估计可用于收集shuffle块的执行程序内存量？
问题3:我已经看到了"当你的数据集无法适应内存时发生随机溢出"的说法,但我的理解是,只要shuffle-reserved执行器内存大到足以包含所有(未压缩)的shuffle输入块ACTIVE任务,然后不应该发生溢出,这是正确的吗？
如果是这样,为了避免溢出,需要确保在所有并行reduce方面任务中结束的(未压缩)数据小于执行程序的shuffle-reserved内存部分？
1.6 之前和之后的内存管理存在差异。在这两种情况下，都有执行内存和存储内存的概念。不同的是，在 1.6 之前它是静态的。这意味着有一个配置参数指定有多少内存用于执行和存储。当任何一个都不够时，就会发生溢出。
Apache Spark 必须解决的问题之一是并发执行：
?
我会说你的理解是正确的。
内存中的内容未压缩，否则无法处理。执行内存以块的形式溢出到磁盘，并且正如您提到的可以压缩。
嗯，从1.3.1开始就可以配置了，那你就知道大小了。至于在任何时候还剩下什么，您可以通过使用类似jstat -gcutil <pid> <period>. 它可能会为您提供有关那里有多少可用内存的线索。知道为存储和执行配置了多少内存，尽可能少default.parallelism可能会给你一个线索。
这是真的，但很难推理；数据中可能存在偏差，例如某些键的值比其他键多，有许多并行执行等。
| 归档时间： |
|
| 查看次数： |
4766 次 |
| 最近记录： |