Spark- memory management tuning

This article is a summary of the content of the official website of the learning process, most of the original, with its own study notes! ! !

• spark 2.0+ memory model
  

Three factors need to be considered when tuning memory usage:

1. The amount of memory used by the object (you may want your entire data set can be loaded into memory);
2. The cost of access to these objects
   
3. Garbage collection overhead (if the object is a high turnover rate).

By default, Java object access is fast, but can easily consume 2-5 times more space than the field of "raw" data. This is due to several reasons:

1. Each has a different Java objects object header, which is about 16 bytes, which contains a pointer to the class information and the like. For a few objects (such as an Int field) of data, it can be larger than the data.
   
2. Java string on the character string data about the original 40 bytes of overhead (because they are stored in the array of characters, and stores the additional data, such as length), since the internal string using UTF-16 code, each character They are stored as two bytes. Thus, a 10-character string can easily consume 60 bytes.
   
3. Public collections, such as HashMapand LinkedList, the link data structure, wherein each entry has a "wrapper" object (e.g. Map.Entry). This object is not only a header, but also point to a next list pointer to an object (typically 8 bytes per pointer).
   4. A set of basic types typically store them as a "boxed" objects, such as java.lang.Integer.

Memory usage Spark mainly divided into two categories: execution and storage.
Execution memory : refers to the shuffles, joins, sorts , aggregationsmemory for the calculation;
Storage Memory : refers to the internal memory cache and the data spread in the cluster;
in Spark, and performs a unified shared storage area (M), when no execution memory, storage access to all available memory, and vice versa;
if necessary, the implementation of storage may be deleted, but only if the total storage memory usage falls below a certain threshold (R) storage will be deleted.

This design ensures that several desirable properties:

1. 首先，不使用缓存的应用程序可以使用整个空间执行，从而避免不必要的磁盘溢出；
2. 其次，确实使用缓存的应用程序可以保留一个最小的存储空间(R)，在这里它们的数据块不会被驱逐；
3. 最后，这种方法为各种工作负载提供了合理的开箱即用性能，而不需要用户了解如何在内部划分内存。

虽然有两种相关配置，但由于默认值适用于大多数工作负载，一般用户不需要调整它们:
spark.memory.fraction:用 M 表示 (JVM heap space - 300MB) (default 0.6)的一部分,其余的空间(40%)预留给用户数据结构、Spark中的内部元数据，以及在稀疏且异常大的记录情况下防止OOM错误。
spark.memory.storageFraction：用R表示M的一部分(默认值为0.5)。R是M中的存储空间，其中缓存的块不会被执行驱逐。

• 优化数据结构：

  减少内存消耗的第一种方法是避免增加开销的Java特性，比如基于指针的数据结构和包装器对象。有几种方法可以做到这一点:

  1. 设计数据结构选择对象数组和基本类型，而不是标准的Java或Scala集合类(例如HashMap)。fastutil库为与Java标准库兼容的基本类型提供了方便的集合类。
  2. 在可能的情况下，避免使用包含大量小对象和指针的嵌套结构。
  3. 考虑使用numeric IDs或enumeration objects对象代替键的字符串。
  4. 如果内存不足32 GB，可以设置JVM标志-XX:+UseCompressedOops，使指针由8个字节变为4个字节。您可以在spark-env.sh中添加这些选项。

• 序列化RDD存储:

  当对象仍然太大而无法有效地存储(尽管进行之前调优)时，减少内存使用的一个更简单的方法是使用RDD持久化API中的序列化存储级别(如MEMORY_ONLY_SER)以序列化的形式存储它们。
  Spark然后将每个RDD分区存储为一个大字节数组。以序列化形式存储数据的惟一缺点是访问时间较慢，因为必须动态地反序列化每个对象。
  如果希望以序列化的形式缓存数据，强烈建议使用Kryo，因为它比Java序列化(当然也比原始Java对象)的大小小得多。

• 垃圾收集调优:

  当您的程序存储了大量的RDDs时，JVM垃圾收集可能是一个问题。(在程序中，只读取RDD一次，然后在上面运行许多操作，这通常不是问题。)当Java需要驱逐旧对象以为新对象腾出空间时，它将需要跟踪所有Java对象并找到未使用的对象。

  这里要记住的要点是，垃圾收集的成本与Java对象的数量成正比，因此使用对象更少的数据结构(例如，一个int数组而不是一个LinkedList)可以大大降低此成本。一个更好的方法是以序列化的形式持久化对象，如上所述:现在每个RDD分区只有一个对象(一个字节数组)。在尝试其他技术之前，如果GC存在问题，首先要尝试的是使用序列化缓存。

  由于任务的工作内存(运行任务所需的空间量)和缓存在节点上的RDDs之间存在干扰，GC也可能成为一个问题。我们将讨论如何控制分配给RDD缓存的空间来缓解这种情况。

• 测量GC的影响（Measuring the Impact of GC ）:

  GC调优的第一步是收集关于垃圾收集发生频率和花费GC的时间的统计信息。这可以通过向Java选项添加-verbose:gc -XX:+PrintGCDetails -XX:+ printgctimestamp来实现。下一次运行Spark作业时，每次发生垃圾收集时，您将看到打印在worker’s logs的消息。
  注意，这些日志将在集群的工作节点上(在工作节点中的stdout文件中)，而不是在驱动程序上。
  有关传递Java选项来触发作业的信息，请参阅配置指南

• 高级GC调优（Advanced GC Tuning）
  

为了进一步优化垃圾收集，我们首先需要了解JVM中内存管理的一些基本信息:

1. Java堆空间分为两个区域，年轻的和年老的。年轻代的目的是保存短期对象，而老代的目的是保存寿命更长的对象。
   
2. 年轻一代被进一步划分为三个区域[Eden, Survivor1, Survivor2]。
   
3. 垃圾收集过程的简化描述:当Eden已满时，在Eden上运行一个小型GC，将Eden和Survivor1中的活动对象复制到Survivor2。将交换Survivor区域。如果一个对象足够老或Survivor2已满，则将其移动到旧的。最后，当Old接近full时，将调用一个full GC。

Minor GC——复制算法具体过程：

1. 将Eden和S0中还存活着的对象一次性的复制到S1中，并且清理掉Eden与S0的空间。如果S1放不下还存活着的对象，那这些对象将通过分配担保机制进入老年代。【原理上随时保持S0和S1有一个是空的，用来存下一次的对象】
2. Eden区快满的时候，会进行上一步类似操作，将Eden和S1区的年纪大的对象放到S0区【此时S1区就是空的】
3. 直到Eden区快满，S0或者S1也快满的时候，这时候就把这两个区的年纪大的对象放到Old区。
4. 依次循环，直到Old区也快满的时候，Eden区也快满的时候，会对整个这一块内存区域进行一次大清洗（FullGC），腾出内存，为之后的对象创建，程序运行腾地方。
   来源：jdk1.8——jvm分析与调优

在Spark中进行GC调优的目标是确保只有长生命周期的RDDs存储在老一代中，并且年轻一代的大小足以存储短生命周期的对象。这将有助于避免Major GC在任务执行期间创建的临时对象。以下是一些可能有用的步骤:

1. 通过收集GC统计信息来检查是否有太多的垃圾收集。如果在任务完成之前多次调用Major GC，这意味着没有足够的内存可用来执行任务。

2. 如果有太多的Minor GC而没有太多的Major GC，那么为Eden分配更多的内存将会有所帮助。您可以将Eden的大小设置为高估于每个任务需要内存的值。如果Eden的大小被确定为E，那么可以使用选项-Xmn=4/3*EE设置年轻一代的大小。(按比例增加4/3是考虑到survivor regions使用的空间)

3. 在打印的GC统计数据中，如果老年代本接近满，则通过降低spark.memory.fraction来减少用于缓存的内存大小;缓存更少的对象比降低任务执行速度要好。
   或者，考虑减少年轻一代的规模。如果你把它设为上面的值意味着降低-Xmn。
   如果没有，尝试更改JVM’s NewRatio参数的值。许多jvm将这个值默认为2，这意味着老年代占用了堆的2/3。它应该足够大，使这个分数超过spark.memory.fraction。

4. 尝试使用-XX:+UseG1GC指定G1GC垃圾收集器。在垃圾收集成为瓶颈的某些情况下，它可以提高性能。
   注意，对于较大的执行器堆大小，使用-XX:G1HeapRegionSize增加G1区域大小可能很重要。

5. 如果任务正在从HDFS读取数据，则可以使用从HDFS读取的数据块大小来估计任务所使用的内存量。
   注意，解压缩块的大小通常是块大小的2或3倍。因此，如果我们希望有3或4个任务的工作空间，并且HDFS块大小为128MB，我们可以估计Eden的大小为4*3*128MB。

6. 监视垃圾收集的频率和时间如何随着新设置而变化。

excutor的调优标志可以由spark.executor.extraJavaOptions指定。
管理完全GC发生的频率有助于减少开销。
关于GC调优更多的参考：Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide

• 级别的并行性 (Level of Parallelism)

  除非为每个操作设置足够高的并行度，否则集群不会得到充分利用。
  Spark根据每个文件的大小自动设置要在每个文件上运行的“map”任务的数量(尽管您可以通过SparkContext.textFile的可选参数来控制它)。
  对于分布式的reduce操作，例如groupByKey和reduceByKey，它使用最大的父RDD分区数。您可以将并行度级别作为参数传递(如：def reduceByKey(func: (V, V) ⇒ V, numPartitions: Int): RDD[(K, V)])。，或设置配置属性spark.default.parallelism来更改默认值。通常，建议在集群中每个CPU内核执行2-3个任务。

• 减少任务的内存使用 (Memory Usage of Reduce Tasks)

  有时候，会报OutOfMemoryError错误，不是因为RDDs的内存设置不适合，而是因为一个任务的工作集(例如groupByKey中的一个reduce任务)太大。
  Spark的shuffle操作(sortByKey、groupByKey、reduceByKey、join等)在每个任务中构建一个哈希表来执行分组，分组常常很大。这里最简单的修复方法是增加并行度，这样每个任务的输入集就会更小。
  Spark可以有效地支持短至200 ms的任务，因为它跨多个任务重用一个executor JVM，并且任务启动成本很低，所以可以安全地将并行性级别提高到集群中的核心数量以上。

• 广播大变量(Broadcasting Large Variables)

  使用SparkContext中可用的广播功能可以极大地减少每个序列化任务的大小，以及通过集群启动作业的成本。
  如果任务使用驱动程序中的任何大对象(例如静态查找表)，考虑将其转换为广播变量。
  Spark在主控器上打印每个任务的序列化大小，因此可以查看它来确定任务是否太大;一般来说，大于20 KB的任务可能值得优化。
  参考：Broadcast Variables

• 数据本地性(Data Locality)

  数据位置对Spark作业的性能有很大的影响。如果数据和对其进行操作的代码在一起，那么计算往往会很快。但是，如果代码和数据是分开的，那么其中一个必须转移到另一个。
  通常，将序列化的代码从一个地方传送到另一个地方要比传送数据块快得多，因为代码的大小比数据小得多。
  Spark根据数据局部性的一般原则构建其调度。
  数据局部性是指数据与处理数据的代码之间的距离。根据数据的当前位置，有几个级别的局部性。
  从最近到最远:
  PROCESS_LOCAL:数据与运行代码位于同一个JVM中。这是最好的地点;
  NODE_LOCAL:数据在同一个节点上。可能在同一节点上的HDFS中，或者在同一节点上的另一个执行器中。这比PROCESS_LOCAL稍微慢一些，因为数据必须在进程之间传递;
  NO_PREF:从任何地方访问数据的速度都一样快，而且没有区域性首选项;
  RACK_LOCAL:数据位于相同的服务器机架上。数据位于同一机架上的不同服务器上，因此需要通过网络发送数据，通常通过一个交换机;
  ANY:数据在网络的其他地方，不在同一个机架上。

  Spark倾向于将所有任务安排在最佳位置级别，但这并不总是可能的。
  在任何空闲执行器上都没有未处理的数据的情况下，Spark切换到较低的局部性级别。
  有两种选择:

  1. 等待繁忙的CPU释放空闲来启动同一服务器上数据上的任务；
  2. 立即在需要移动数据的较远的地方启动新任务。
     Spark通常做的是等待一段时间，希望繁忙的CPU释放。一旦超时过期，它就开始将数据从很远的地方移动到空闲的CPU。每个级别之间回退的等待超时可以单独配置，也可以全部配置在一个spark.locality中。

本文为本人学习总结文章，转载请注明出处！！！！