Spark支持溢写磁盘，为何仍会出现OOM内存溢出？

场景1：Executor间shuffle数据传输引发OOM #

• Shuffle接收端的内存缓冲有上限，要是数据涌入速度远快于溢写磁盘的速度，会先把Executor堆内存撑爆。比如新版Spark用spark.memory.fraction分配执行内存，要是shuffle数据占比超过这个值，溢写还没启动，内存就不够了。
• 序列化方式选得不好也会出问题，比如Java序列化反序列化后，对象占用内存比原字节流大好几倍，这时候哪怕原本数据能溢写，反序列化后的对象直接就把内存占满了，溢写机制根本没机会介入。
• 合并shuffle文件的时候，内存缓冲区如果设置不合理，或者同时合并的文件太多，这部分内存开销不在溢写机制的覆盖范围内，也会直接导致OOM。

场景2：coalesce(1)触发shuffle时OOM #

• coalesce(1)会把所有数据集中到单个Executor的单个Task里，这个Task要处理的是全量数据。哪怕溢写机制能处理单块数据，但如果单次读入的数据块大小就超过了Executor剩余内存，直接就OOM了，根本轮不到溢写。
• reduce端接收数据时，所有map端的数据都往这一个节点发，内存缓冲瞬间被填满，溢写线程的处理速度赶不上数据接收速度，内存直接耗尽。另外map端写shuffle文件时，如果缓冲区和排序内存不够，溢写前就会把内存用光。

场景3：Driver执行collect()时OOM #

• Spark的溢写机制只管Executor端的Task，Driver端根本没有自动溢写的逻辑。调用collect()时，所有Executor的数据会一次性全拉到Driver的堆内存里，只要数据量超过Driver的可用内存，直接就OOM，没有任何磁盘溢写的环节。
• 很多人只给Executor配大内存，忽略Driver的默认配置（只有1G），超大数据集拉过来直接就把Driver内存撑爆，哪怕想分批处理，collect()本身就是一次性加载，根本没机会补救。

内容的提问来源于stack exchange，提问作者ng.newbie