hadoop - 当 mapred.job.shuffle.input.buffer.percent=0.70 时，pig join 在 reducer 中出现 OutOfMemoryError

Question

我们正在一个小表和一个大倾斜表之间进行简单的 pig 连接。由于另一个错误 (pig skewed join with a big table causes "Split metadata size exceeded 10000000")，我们无法使用 "using skewed" :(

如果我们使用默认的 mapred.job.shuffle.input.buffer.percent=0.70 我们的一些 reducer 在 shuffle 阶段会失败:

org.apache.hadoop.mapred.Task: attempt_201305151351_21567_r_000236_0 : 
Map output copy failure : java.lang.OutOfMemoryError: GC overhead limit exceeded

如果我们将其更改为 mapred.job.shuffle.input.buffer.percent=0.30 它会很好地完成，尽管需要 2 小时(我们使用的 1000 个 reducer 中有 3 个滞后 reducer ) ，我们可以在滞后的 reducer 日志中看到如下内容:

SpillableMemoryManager: first memory handler call- 
Usage threshold init = 715849728(699072K) used = 504241680(492423K) committed = 715849728(699072K) max = 715849728(699072K)

为什么会这样？当 shuffle 输入缓冲区达到 70% 时，SpliableMemoryManager 为何不能保护我们免于失败？

Answer 1

一般来说，mapred.job.shuffle.input.buffer.percent=0.70 不会触发 OutOfMemory 错误，因为此配置可确保最多 70% 的 reducer 堆用于存储打乱后的数据。但是，在我的实践中有两种情况可能会导致OutOfMemory错误。

1) 你的程序有 combine() 函数，你的 combine() 很耗内存。因此在 shuffle 阶段内存使用可能会超过 heap 的 70%，这可能会导致 OutOfMemory 错误。但一般情况下，Pig 在 Join 运算符中没有 combine() 。

2)JVM自己管理内存，将其堆划分为Eden、S0、S1和old space。 S0 和 S1 用于 GC。在某些情况下，S0 + S1 + 部分混洗数据(70% 堆)> 堆大小。所以发生了OutOfMemory。

正如你所说，当mapred.job.shuffle.input.buffer.percent=0.30时，只有30%的heap用于存储shuffle后的数据，heap很难被填满。我需要job的详细配置(比如Xmx)，数据大小，log，给你一个更具体的答案。

说到 SpillableMemoryManager。 Pig 中默认的集合数据结构是一个“Bag”。包是可溢出的，这意味着如果没有足够的内存来容纳 RAM 中包中的所有元组，Pig 会将包的一部分溢出到磁盘。这允许大型作业取得进展，尽管速度很慢，而不是因“内存不足”错误而崩溃。 (本段来自pig's blog)

但是shuffle阶段是由Hadoop自己控制的，所以SpillableMemoryManager在shuffle阶段是不会生效的(确切的说是可以在Group By中使用的combine()中生效。但是Join没有combine() ). SpillableMemoryManager 通常用在 map()、combine()、reduce() 函数中。这就是为什么当 shuffle 输入缓冲区为 70% 时，SpliableMemoryManager 不能保护我们免于失败。请注意，Hadoop 不会将所有打乱后的数据保存在内存中，如果数据太大，它会将部分打乱后的数据合并到磁盘上。