1.gc时间过长
在spark ui上的现象是时间过长且gc的时间比较长，现象截图如下：
原理分析
日常使用中，我们通过spark.executor.memory来控制一个executor最多可以使用的内存大小，实际上是通过设置Executor的JVM的Heap大小实现的。
Executor的内存界限分明，分别由3部分组成：execution,storage和system。
-
execution
execution空间通过设置spark.shuffle.memoryFraction参数来控制大小，默认为0.2。为了避免shuffle，join，排序和聚合这些操作直接将数据写入磁盘，所设置的buffer大小，减少了磁盘读写的次数。 -
storage
storage空间通过设置spark.storage.memoryFraction参数来控制大小，默认为0.6。用于存储用户显示调用的persist,cache,broadcast等命令存储的数据空间。 -
system
程序运行需要的空间，存储一些spark内部的元数据信息，用户的数据结构，避免一些不寻常的大记录带来的OOM。
之前的管理方式，最明显的就是对execution和storage空间进行了明显的划分。举个例子，一些任务可能对数据缓存的需求并不是很高，就会造成storage空间的浪费。
|
spark.executor.memory
|
spark.storage.memoryFraction | spark.shuffle.memoryFraction | |
| 原来 | 36G | 默认值0.6 | 默认值0.2 |
| 修改后 | 48G | 0.4 | 0.5 |
修改后的spark ui 截图，处理时间从22分钟降到4.3分钟
