免费行情网站排名,新乡做网站的公司,杭州制作网站的公司,一般通过中介找工作需要多少钱目录
前言
Java内存管理
Java运行时数据区
Java堆
新生代与老年代
永久代
元空间
垃圾回收机制
JVM GC的类型和策略
Minor GC
Major GC
分代GC
Full GC
Minor GC 和 Full GC区别
Executor内存管理
内存类型
堆内内存
堆外内存
内存管理模式
静态内存管理
…目录
前言
Java内存管理
Java运行时数据区
Java堆
新生代与老年代
永久代
元空间
垃圾回收机制
JVM GC的类型和策略
Minor GC
Major GC
分代GC
Full GC
Minor GC 和 Full GC区别
Executor内存管理
内存类型
堆内内存
堆外内存
内存管理模式
静态内存管理
统一内存管理
编辑
执行内存管理
多任务间内存分配
Shuffle 的内存占用
MemoryOverHead详解
任务内存调节
错误类型及调整方案
1. Executor OOM类错误 错误代码 137、143等
方式一增加单个task的内存使用量
方式二降低单个Task的内存消耗量
2. Beyond xxx memory, killed by yarn
情况1不存在子进程
情况2存在子进程
可用内存计算
常见问题
SparkSQL导致的JVM栈内存溢出
YARN-CLUSTER 模式的 JVM 栈内存溢出无法执行问题
频繁 GC 问题
JVM GC 导致的 shuffle 文件拉取失败 前言
Spark的Driver和Executor作为一个JVM进程其内存管理是建立在JVM的内存管理之上的。
Java内存管理
Java运行时数据区 方法区它用于存储每个类的结构信息如运行时常量池、字段和方法数据、构造函数等内容。可共各个线程共享的内存区域Java堆所有类的实例和数组对象分配的内存区域这个区域是所有线程共享的内存区域PC寄存器用于CPU运行多线程时记录每个线程Java虚拟机正在执行的字节码指令的地址Java虚拟机栈每个线程都有自己私有的Java虚拟机栈。随线程创建而创建随线程消失而销售。每个线程中方法的调用都是通过Java虚拟机栈传递的。每个方法的调用都会生成对应的栈帧(Frame)压栈方法执行结束时对应的栈帧出栈从而形成一些列的方法调用过程栈帧是一种用来存储数据和部分过程结果的数据结构同时栈帧也用来处理动态链接、方法返回值和异常的派发本地方法栈用传统的栈来支持native方法的执行。创建线程时按线程分配。
Java堆
新生代与老年代
Java堆内存包含两部分
新生代包括Eden区From Survivor区(S0)To Survivor区(S1)Eden:S0:S1 8:1:1老年代新生代 : 老年代 1 : 2即年轻代占整个堆内存的1/3老年代占2/3
通常对象在Eden区分配经过一次新生代垃圾回收后存活的对象被整理到S0或者S1同时对象的年龄会加1对象的年龄达到一定条件后会进入老年代。 永久代
永久代是hotspot虚拟机也就是我们使用的java虚拟机的特有的概念他不属于堆内存是方法区的一种实现各大厂商对方法区有各自的实现。永久代存放jvm运行时需要的类包含java库的类和方法在触发full gc的情况下永久代也会被进行垃圾回收。永久代的内存溢出也就是 pergen space。
元空间
元空间是metaspace在jdk1.8的时候jvm移除了永久代的概念元空间也是对java虚拟机的方法区的一种实现。元空间与永久代最大的区别在于元空间不在虚拟机中使用本地内存。通过配置如下参数可以更改元空间的大小。 -XX:MetaspaceSize初始空间的大小。达到该值就会触发垃圾收集进行类型卸载同时GC会对该值进行调整如果释放了大量的空间就适当降低该值如果释放了很少的空间那么在不超过MaxMetaspaceSize时适当提高该值。 -XX:MaxMetaspaceSize最大空间默认是没有限制的。 永久代的回收会随着full gc进行移动消耗性能。每种类型的垃圾回收都需要特殊处理元数据。将元数据剥离出来简化了垃圾收集提高了效率。
垃圾回收机制
垃圾回收Garbage CollectionGC针对的是Java堆和方法区。
Java堆和方法区两部分区域的生命周期是和整个Java应用程序相关联的需要进行垃圾回收。而Java运行时数据区的其他部分如Java虚拟机栈Java本地方法栈和PC寄存器是与每个线程的生命周期关联的随线程创建与消亡不需要进行垃圾回收。
判断一个对象是否回收的方法可达性分析。找到一些列根对象一般的根对象可以是Java虚拟机栈引用对象、方法区中静态属性和常量引用对象、本地方法栈引用对象等。以这一系列根对象为起点向下搜索其引用的对象当一个对象从根对象不可达时则认为这个对象可以被回收了。
Java的引用共分为4种强引用、软引用、弱引用、虚引用引用关系强度依次减弱。
强引用垃圾回收器不会回收。软引用发生内存溢出前会把这类对象列入回收范围之内进行二次回收。回收后内存还是不足则抛出内存溢出的异常。SoftReference。弱引用垃圾回收时无论内存是否充足都会回收。WeakReference。虚引用不对垃圾回收产生影响。只是为了垃圾回收时能够收到一个系统的通知。
垃圾回收算法
引用计数法缺点是无法处理循环引用每次新增引用或清除引用时都要加减操作影响性能标记清除算法分标记阶段和清除阶段。缺点是垃圾回收后会产生大量的内存碎片影响内存分配效率标记压缩算法在标记清除算法基础上垃圾清理之后将剩余存活的对象进行一次整理统一移动到连续的内存空间中虽然解决了内存不连续的问题但是在压缩阶段会有额外的移动工作复制算法分S0和S1两块内存区域每次使用其中一个区域当使用区域用完时执行垃圾回收将存活的对象复制到另外一个区域然后将已使用的这块区域清空。优点是分配速度快运行高效缺点是内存浪费太严重。分区算法将整个堆空间划分成多个连续的更小的空间每个空间独立分配独立回收。可以有效控制GC停顿时长分代思想对象分两种一种存在生命周期较短的一种生命周期较长的相应的把内存划分为新生代存储生命周期较短的老年代存储生命周期较长的。老年代适合用标记清除算法、标记压缩算法新生代适合复制算法。新生代划分为eden、from、to三个区from和to也称为幸存区(survive)分别为S0、S1。
垃圾回收器
串行收集器单线程运行会暂停应用中其他线程直至回收完毕可用于新生代和老年代并行收集器多线程并行运行分为ParNew(新生代)、ParallelGC(新生代)、ParallelOldGC(老年代)CMS收集器CMS并发标记清除以获得最短垃圾回收时间为目标减少系统停顿一般应用在一些Web服务中。G1垃圾收集器面向服务端应用充分利用多核CPU的优势缩短垃圾回收时用户线程停顿时长回收过程与CMS类似但可与用户线程同时执行。可用于整堆内存回收。
JVM GC的类型和策略
大家经常混淆的Minor GC、Major GC、Full GC年轻代GC、老年代GC之间有什么区别和联系。 Minor GC
JVM堆内存被分为两部分年轻代Young Generation和老年代Old Generation。 1.年轻代
年轻代是所有新对象产生的地方,当年轻代内存空间被用完时就会触发垃圾回收,这个垃圾回收叫做Minor GC。
年轻代被分为3个部分——Enden区和两个Survivor区,年轻代空间的要点
大多数新建的对象都位于Eden区。当Eden区被对象填满时就会执行Minor GC。并把所有存活下来的对象转移到其中一个survivor区。Minor GC同样会检查存活下来的对象并把它们转移到另一个survivor区。这样在一段时间内总会有一个空的survivor区。经过多次GC周期后仍然存活下来的对象会被转移到年老代内存空间。通常这是在年轻代有资格提升到年老代前通过设定年龄阈值来完成的。
2.年老代
年老代内存里包含了长期存活的对象和经过多次Minor GC后依然存活下来的对象通常会在老年代内存被占满时进行垃圾回收。
Major GC
老年代的垃圾收集叫做Major GCMajor GC通常是跟full GC是等价的收集整个GC堆。
Minor GC和Major GC其实就是年轻代GC和年老年GC的俗称。而在Hotspot VM具体实现的收集器Serial GC, Parallel GC, CMS, G1 GC中大致可以对应到某个Young GC和Old GC算法组合。
分代GC
针对HotSpot VM的实现其实GC的准确分类可以分为
分代GCFull GC
以及后续的G1的分区收集本质其实还是一个分代收集器但是和之前的各类回收器不同它同时兼顾年轻代和老年代。
分代GC并不收集整个GC堆的模式而是只专注分代收集
Young GC只收集年轻代的GCOld GC只收集年老代的GC(只有CMS的concurrent collection是这个模式)Mixed GC收集整个young gen以及部分old gen的GC(只有G1有这个模式)
Full GC
Full GC定义是相对明确的就是针对整个新生代、老生代、元空间metaspacejava8以上版本取代perm gen的全局范围的GC。
Minor GC 和 Full GC区别
新生代 GCMinor GC:指发生新生代的的垃圾收集动作Minor GC 非常频繁回收速度一般也比较快。
老年代 GCMajor GC/Full GC:指发生在老年代的 GC出现了 Major GC 经常会伴随至少一次的 Minor GC并非绝对Major GC 的速度一般会比 Minor GC 的慢 10 倍以上。
Executor内存管理
内存类型
包含两种方式堆内内存和堆外内存。一个 Executor 当中的所有 Task 是共享堆内内存的。一个 Worker 中的多个 Executor 中的多个 Task 是共享堆外内存的。 堆内内存
堆内内存大小由 Spark 程序启动时的 --executor-memory 或 spark.executor.memory 参数配置。那 Spark 是如何管理堆内内存呢Spark 对堆内内存的管理是一种逻辑上的“规划式”的管理因为对象实例占用内存的申请和释放都由 JVM 完成的。
堆外内存
Spark1.6在堆内内存的基础上引入了堆外内存进一步优化了Spark内存的使用率。其实如果你有过Java相关编程经历的话相信对堆外内存的使用并不陌生。其底层调用基于C的JDK Unsafe类方法通过指针直接进行内存的操作包括内存空间的申请、使用、删除释放等。
Spark在2.x之后摒弃了之前版本的Tachyon采用Java中常见的基于JDK Unsafe API来对堆外内存进行管理。此模式不在JVM中申请内存直接操作系统内存减少了JVM中内存空间切换的开销降低了GC回收占用的消耗实现对内存的精确管控。
堆外内存默认情况下是不开启的需要在配置中将spark.memory.offHeap.enabled设为True,同时配置spark.memory.offHeap.size参数设置堆大小。对于堆外内存的划分仅包含Execution(执行内存)和Storage(存储内存)两块区域且被所有task线程任务共享。
spark.memory.offHeap.enabledtrue # 开启堆外内存
spark.memory.offHeap.size 1073741824 # 分配堆外内存的大小,单位byte
内存管理模式
在Spark1.6之前Spark采用的是静态管理(Static Memory Manager)模式Execution内存和Storage内存的分配占比全部是静态的其值为系统预先设置的默认参数。
在Spark1.6后为了考虑内存管理的动态灵活性Spark的内存管理改为统一管理(Unified Memory Manager)模式支持Storage和Execution内存动态占用。至于静态管理方式任然被保留可通过spark.memory.useLegacyMode参数启用。
静态内存管理 在 Spark 最初采用的静态内存管理机制下存储内存、执行内存和其他内存的大小在 Spark 应用程序运行期间均为固定的但用户可以应用程序启动前进行配置其优点是实现机制简单易理解缺点是容易出现内存失衡的问题即Storage、Execution一方内存过剩一方内容不足另外需要开发人员充分了解存储机制调优不便。堆内内存的分配如图所示 堆内内存空间整体被分为Storage(存储内存)、Execution(执行内存)、Other(其他内存)三部分,默认按照6:2:2的比率划分。其中Storage内存区域参数: spark.storage.memoryFraction(默认为0.6)Execution内存区域参数: spark.shuffle.memoryFraction(默认为0.2)。其中Other内存区域主要用来存储用户定义的数据结构、Spark内部元数据占系统内存的20%。
堆外内存由参数spark.memory.storageFraction(默认0.5)控制。 统一内存管理 为了解决(Static Memory Manager)静态内存管理的内存失衡等问题Spark在1.6之后使用了一种新的内存管理模式—Unified Memory Manager(统一内存管理)。在新模式下移除了旧模式下的Executor内存静态占比分配启用了内存动态占比机制并将Storage和Execution划分为统一共享内存区域。 堆内内存整体划分为Usable Memory(可用内存)和Reversed Memory(预留内存)两大部分。其中预留内存作为OOM等异常情况的内存使用区域默认被分配300M的空间。可用内存可进一步分为(Unified Memory)统一内存和Other内存其他两部分默认占比为64。
Storage Memory 存储内存用于存放广播数据及RDD缓存数据。Execution Memory 执行内存用于缓存执行Shuffle过程中产生的中间数据。Other Memory 其他内存用于存放用户自定义的数据结构或Spark内部元数据。 在默认情况下堆外内存并不启用可通过配置 spark.memory.offHeap.enabled 参数启用并由spark.memory.offHeap.size 参数设定堆外空间的大小。除了没有 other 空间堆外内存与堆内内存的划分方式相同如下图所示(以统一内存管理机制为例)所有运行中的并发任务共享存储内存和执行内存。 动态占用机制示意图
执行内存管理
多任务间内存分配
Executor 内运行的任务同样共享执行内存Spark 用一个 HashMap 结构保存了任务到内存耗费的映射。每个任务可占用的执行内存大小的范围为 1/2N ~ 1/N其中 N 为当前 Executor 内正在运行的任务的个数。每个任务在启动之时要向 MemoryManager 请求申请最少为 1/2N 的执行内存如果不能被满足要求则该任务被阻塞直到有其他任务释放了足够的执行内存该任务才可以被唤醒。
Shuffle 的内存占用
执行内存主要用来存储任务在执行 Shuffle 时占用的内存Shuffle 是按照一定规则对 RDD 数据重新分区的过程我们来看 Shuffle 的 Write 和 Read 两阶段对执行内存的使用
Shuffle Write
若在 map 端选择普通的排序方式会采用 ExternalSorter 进行外排在内存中存储数据时主要占用堆内执行空间。若在 map 端选择 Tungsten 的排序方式则采用 ShuffleExternalSorter 直接对以序列化形式存储的数据排序在内存中存储数据时可以占用堆外或堆内执行空间取决于用户是否开启了堆外内存以及堆外执行内存是否足够。
Shuffle Read
在对 reduce 端的数据进行聚合时要将数据交给 Aggregator 处理在内存中存储数据时占用堆内执行空间。
如果需要进行最终结果排序则要将再次将数据交给 ExternalSorter 处理占用堆内执行空间。
在 ExternalSorter 和 Aggregator 中Spark 会使用一种叫 AppendOnlyMap 的哈希表在堆内执行内存中存储数据但在 Shuffle 过程中所有数据并不能都保存到该哈希表中当这个哈希表占用的内存会进行周期性地采样估算当其大到一定程度无法再从 MemoryManager(BlockManager里的MemoryStore里的memoryManager) 申请到新的执行内存时Spark 就会将其全部内容存储到磁盘文件中这个过程被称为溢存(Spill)溢存到磁盘的文件最后会被归并(Merge)。
Shuffle Write 阶段中用到的 Tungsten 是 Databricks 公司提出的对 Spark 优化内存和 CPU 使用的计划解决了一些 JVM 在性能上的限制和弊端。Spark 会根据 Shuffle 的情况来自动选择是否采用 Tungsten 排序。Tungsten 采用的页式内存管理机制建立在 MemoryManager 之上即 Tungsten 对执行内存的使用进行了一步的抽象这样在 Shuffle 过程中无需关心数据具体存储在堆内还是堆外。每个内存页用一个 MemoryBlock 来定义并用 Object obj 和 long offset 这两个变量统一标识一个内存页在系统内存中的地址。堆内的 MemoryBlock 是以 long 型数组的形式分配的内存其 obj 的值为是这个数组的对象引用offset 是 long 型数组的在 JVM 中的初始偏移地址两者配合使用可以定位这个数组在堆内的绝对地址堆外的 MemoryBlock 是直接申请到的内存块其 obj 为 nulloffset 是这个内存块在系统内存中的 64 位绝对地址。Spark 用 MemoryBlock 巧妙地将堆内和堆外内存页统一抽象封装并用页表(pageTable)管理每个 Task 申请到的内存页。
Tungsten 页式管理下的所有内存用 64 位的逻辑地址表示由页号和页内偏移量组成
页号占 13 位唯一标识一个内存页Spark 在申请内存页之前要先申请空闲页号。页内偏移量占 51 位是在使用内存页存储数据时数据在页内的偏移地址。
有了统一的寻址方式Spark 可以用 64 位逻辑地址的指针定位到堆内或堆外的内存整个 Shuffle Write 排序的过程只需要对指针进行排序并且无需反序列化整个过程非常高效对于内存访问效率和 CPU 使用效率带来了明显的提升。
Spark 的存储内存和执行内存有着截然不同的管理方式对于存储内存来说Spark 用一个 LinkedHashMap 来集中管理所有的 BlockBlock 由需要缓存的 RDD 的 Partition 转化而成而对于执行内存Spark 用 AppendOnlyMap 来存储 Shuffle 过程中的数据在 Tungsten 排序中甚至抽象成为页式内存管理开辟了全新的 JVM 内存管理机制。
MemoryOverHead详解
看过官方文档我们知到spark.executor(driver).memoryOverhead 主要就是保证Yarn/K8s模式下 Executor 运行时的稳定性。
那么spark.memory.offHeap.size和spark.executor.memoryOverhead两个参数都是控制堆外内存大小那到底有什么区别那
在3.0之前的版本spark.memory.offHeap.size此参数包含于spark.executor.memoryOverhead内也就是spark.memory.offHeap.size的参数值应小于spark.executor.memoryOverhead的参数。而到了3.0之后两块内存互相独立了不再是包含关系。 总结如下spark 2.X
spark.memory.offHeap.size 真正作用于spark executor的堆外内存spark.executor.memoryOverhead 作用于yarn用来保证稳定性 由 yarn.scheduler.maximum-allocation-mb 指定 NodeManager 上container可申请的最大内存提交任务时如果 spark.executor.memoryOverhead 和 Executor Memory 所占的内存之和大于分配的内存之和那就会造成 Executor 提交失败运行过程中超过上限阈值进程会被杀掉。 JVM OffHeap内存大小由”spark.yarn.executor.memoryOverhead”参数指定主要用于JVM自身字符串, NIO Buffer等开销。
如上图所示Yarn集群管理模式中Spark 以Executor Container的形式在NodeManager中运行其可使用的内存上限由“yarn.scheduler.maximum-allocation-mb” 指定, ---我们可以称其为MonitorMemory。
如前所述Executor的内存由Heap内存和设定的Off-heap内存组成。
Heap 由“spark.executor.memory” 指定, 以下称为ExecutorMemoryOff-heap 由 “spark.yarn.executor.memoryOverhead” 指定 以下称为MemoryOverhead
因此, 对现有Yarn集群存在
ExecutorMemory MemoryOverhead MonitorMemory
若应用提交之时指定的 ExecutorMemory与MemoryOverhead 之和大于 MonitorMemory则会导致Executor申请失败若运行过程中实际使用内存超过上限阈值Executor进程会被Yarn终止掉kill。
Executor 中MemoryOverhead内存主要是创建Java Object时的额外开销Native方法调用线程栈 NIO Buffer等开销Driect Buffer。此部分为用户代码及Spark 不可操作的内存不足时可通过调整参数解决, 无需过多关注。 具体需要调整的场景参见下面参数调节部分。
任务内存调节
Executor中可同时运行的任务数由Executor分配的CPU的核数N 和每个任务需要的CPU核心数C决定。其中:
N spark.executor.coresC spark.task.cpus
Executor的最大任务并行度可表示为TP N / C 其中,C值与应用类型有关大部分应用使用默认值1即可因此影响Executor中最大任务并行度的主要因素是N。
依据Task的内存使用特征前文所述的Executor内存模型可以简单抽象为下图所示模型 其中Executor 向yarn申请的总内存可表示为 M M1 M2
错误类型及调整方案
1. Executor OOM类错误 错误代码 137、143等
该类错误一般是由于HeapM2已达上限Task需要更多的内存而又得不到足够的内存而导致。因此解决方案要从增加每个Task的内存使用量满足任务需求 或 降低单个Task的内存消耗量从而使现有内存可以满足任务运行需求两个角度出发。因此
方式一增加单个task的内存使用量
增加最大Heap值 即上图中M2 的值使每个Task可使用内存增加。降低Executor的可用Core的数量 N , 使Executor中同时运行的任务数减少在总资源不变的情况下使每个Task获得的内存相对增加。
方式二降低单个Task的内存消耗量
降低单个Task的内存消耗量可从配制方式和调整应用逻辑两个层面进行优化
配制方式 减少每个Task处理的数据量可降低Task的内存开销在Spark中每个partition对应一个处理任务Task。因此在数据总量一定的前提下可以通过增加partition数量的方式来减少每个Task处理的数据量从而降低Task的内存开销。针对不同的Spark应用类型存在不同的partition调整参数如下
P spark.default.parallism (非SQL应用)P spark.sql.shuffle.partition (SQL 应用)P mapred.reduce.tasks (HiveOnSpark)
通过增加P的值可在一定程度上使Task现有内存满足任务运行 注: 当调整一个参数不能解决问题时上述方案应进行协同调整 ---备注若应用shuffle阶段 spill严重则可以通过调整“spark.shuffle.spill.numElementsForceSpillThreshold”的值来限制spill使用的内存大小比如设置2000000该值太大不足以解决OOM问题若太小则spill会太频繁影响集群性能因此要依据负载类型进行合理伸缩此处可设法引入动态伸缩机制待后续处理。 调整应用逻辑 Executor OOM 一般发生Shuffle阶段该阶段需求计算内存较大且应用逻辑对内存需求有较大影响下面举例就行说明
groupByKey 转换为 reduceByKey 一般情况下groupByKey能实现的功能使用reduceByKey均可实现而ReduceByKey存在Map端的合并可以有效减少传输带宽占用及Reduce端内存消耗。 选择合适的算子
data skew 预处理 Data Skew是指任务间处理的数据量存大较大的差异。 如左图所示key 为010的数据较多当发生shuffle时010所在分区存在大量数据不仅拖慢Job执行Job的执行时间由最后完成的任务决定。 而且导致010对应Task内存消耗过多可能导致OOM. 而右图经过预处理加盐此处仅为举例说明问题解决方法不限于此可以有效减少Data Skew导致 的问题 Data Skew预处理
---注上述举例仅为说明调整应用逻辑可以在一定程序上解决OOM问题解决方法不限于上述举例
2. Beyond xxx memory, killed by yarn
出现该问题原因是由于实际使用内存上限超过申请的内存上限而被Yarn终止掉了, 首先说明Yarn中Container内存监控机制
Container进程的内存使用量以Container进程为根的进程树中所有进程的内存使用总量。Container被杀死的判断依据进程树总内存物理内存或虚拟内存使用量超过向Yarn申请的内存上限值则认为该Container使用内存超量可以被“杀死”。
因此对该异常的分析要从是否存在子进程两个角度出发。
情况1不存在子进程
根据Container进程杀死的条件可知在不存在子进程时出现killed by yarn问题是于由Executor(JVM)进程自身内存超过向Yarn申请的内存总量M 所致。由于未出现第1节所述的OOM异常如果是Executor OOM则会先抛Executor OOM异常而不会抛出killed by yarn异常因此可判定其为 M1(Overhead)不足, 依据Yarn内存使用情况有如下两种方案
如果M未达到Yarn单个Container允许的上限时可仅增加M1 从而增加M如果M达到Yarn单个Container允许的上限时增加 M1 降低 M2.
操作方法在提交脚本中添加 --conf spark.yarn.executor.memoryOverhead3072(或更大的值比如4096等) --conf spark.executor.memory 10g 或 更小的值注意二者之各要小于Container监控内存量,否则伸请资源将被yarn拒绝。
减少可用的Core的数量 N, 使并行任务数减少从而减少Overhead开销
操作方法在提交脚本中添加 --executor-cores3 比原来小的值 或 --conf spark.executor.cores3 比原来小的值
情况2存在子进程
Spark 应用中Container以ExecutorJVM进程的形式存在因此根进程为Executor对应的进程, 而Spark 应用向Yarn申请的总资源M M1 M2 , 都是以ExecutorJVM进程非进程树可用资源的名义申请的。申请的资源并非一次性全量分配给JVM使用而是先为JVM分配初始值随后内存不足时再按比率不断进行扩容直致达到Container监控的最大内存使用量M 。当Executor中启动了子进程调用shell等时子进程占用的内存记为 S 就被加入Container进程树此时就会影响Executor实际可使用内存资源Executor进程实际可使用资源为M - S然而启动JVM时设置的可用最大资源为M 且JVM进程并不会感知Container中留给自己的使用量已被子进程占用因此当JVM使用量达到 M - S还会继续开辟内存空间这就会导致Executor进程树使用的总内存量大于M 而被Yarn 杀死。
典形场景有PySparkSpark已做内存限制一般不会占用过大内存、自定义Shell调用。其解决方案
PySpark场景
如果M未达到Yarn单个Container允许的上限时可仅增加M1 从而增加M如果M达到Yarn单个Container允许的上限时增加 M1 降低 M2减少可用的Core的数量 N, 使并行任务数减少从而减少Overhead开销
自定义Shell 场景OverHead不足为假象
调整子进程可用内存量通过单机测试内存控制在Container监控内存以内且为Spark保留内存等留有空间。方法同上。
可用内存计算 参考Spark内存管理计算详述-CSDN博客 常见问题
SparkSQL导致的JVM栈内存溢出
当 SparkSQL 的 sql 语句有成百上千的 or 关键字时就可能会出现Driver端的JVM栈内存溢出。
JVM 栈内存溢出基本上就是由于调用的方法层级过多产生了大量的非常深的超 出了 JVM 栈深度限制的递归。(我们猜测 SparkSQL 有大量 or 语句的时候在解析 SQL 时 例如转换为语法树或者进行执行计划的生成的时候对于 or 的处理是递归or 非常多时会发生大量的递归)。此时建议将一条 sql 语句拆分为多条 sql 语句来执行每条 sql 语句尽量保证 100 个以内的子句。根据实际的生产环境试验一条 sql 语句的 or 关键字控制在 100 个以内通 常不会导致 JVM 栈内存溢出。
YARN-CLUSTER 模式的 JVM 栈内存溢出无法执行问题
当 Spark 作业中包含 SparkSQL 的内容时可能会碰到 YARN-client 模式下可以运行但是 YARN-cluster 模式下无法提交运行(报出 OOM 错误)的情况。
YARN-client 模式下Driver 是运行在本地机器上的Spark 使用的 JVM 的 PermGen 的 配置是本地机器上的 spark-class 文件JVM 永久代的大小是 128MB这个是没有问题的 但是在 YARN-cluster 模式下Driver 运行在 YARN 集群的某个节点上使用的是没有经过配置的默认设置PermGen 永久代大小为 82MB。
SparkSQL 的内部要进行很复杂的 SQL 的语义解析、语法树转换等等非常复杂如果 sql 语句本身就非常复杂那么很有可能会导致性能的损耗和内存的占用特别是对 PermGen 的占用会比较大。
所以此时如果 PermGen 的占用好过了 82MB但是又小于 128MB就会出现 YARN- client 模式下可以运行YARN-cluster 模式下无法运行的情况。
解决上述问题的方法时增加 PermGen 的容量需要在 spark-submit 脚本中对相关参数 进行设置设置方法如代码清单所示。
--conf spark.driver.extraJavaOptions-XX:PermSize128M -XX:MaxPermSize256M
通过上述方法就设置了 Driver 永久代的大小默认为 128MB最大 256MB这样就可以避免上面所说的问题。
频繁 GC 问题
1、打印 GC 详情
统计一下 GC 启动的频率和 GC 使用的总时间在 spark-submit 提交的时候设置参数
--conf spark.executor.extraJavaOptions-XX:PrintGCDetails -XX:PrintGCTimeStamps
如果出现了多次Full GC首先考虑的是可能配置的Executor内存较低这个时候需要增加 Executor Memory 来调节。
2、如果一个任务结束前Full GC 执行多次说明老年代空间被占满了那么有可能是没有分配足够的内存。
1.调整 executor 的内存配置参数 executor-memory
2.调整老年代所占比例:配置-XX:NewRatio 的比例值
3.降低 spark.memory.storageFraction 减少用于缓存的空间
3、如果有太多 Minor GC但是 Full GC 不多可以给 Eden 分配更多的内存。
1.比如 Eden 代的内存需求量为 E可以设置 Young 代的内存为-Xmn4/3*E,设置该值也会导致 Survivor 区域扩张
2.调整 Eden 在年轻代所占的比例配置-XX:SurvivorRatio 的比例值
4、调整垃圾回收器通常使用 G1GC即配置-XX:UseG1GC。当 Executor 的堆空间比较大时可以提升 G1 region size(-XX:G1HeapRegionSize)在提交参数指定:
--conf spark.executor.extraJavaOptions-XX:UseG1GC -XX:G1HeapRegionSize16M -XX:PrintGCDetails -XX:PrintGCTimeStamps
JVM GC 导致的 shuffle 文件拉取失败
在Spark作业中有时会出现shuffle file not found的错误这是非常常见的一个报错有时出现这种错误以后选择重新执行一遍就不再报出这种错误。
出现上述问题可能的原因是 Shuffle 操作中后面 stage 的 task 想要去上一个 stage 的 task 所在的 Executor 拉取数据结果对方正在执行 GC执行 GC 会导致 Executor 内所有的工作现场全部停止比如 BlockManager、基于 netty 的网络通信等这就会导致后面的 task拉取数据拉取了半天都没有拉取到就会报出shuffle file not found的错误而第二次再次执行就不会再出现这种错误。
可以通过调整 reduce 端拉取数据重试次数和 reduce 端拉取数据时间间隔这两个参数来对 Shuffle 性能进行调整增大参数值使得 reduce 端拉取数据的重试次数增加并且每次失败后等待的时间间隔加长。
val conf new SparkConf()
.set(spark.shuffle.io.maxRetries, 60)
.set(spark.shuffle.io.retryWait, 60s) 文章转载自： http://www.morning.gwwky.cn.gov.cn.gwwky.cn http://www.morning.ctswj.cn.gov.cn.ctswj.cn http://www.morning.fjglf.cn.gov.cn.fjglf.cn http://www.morning.mqwdh.cn.gov.cn.mqwdh.cn http://www.morning.dighk.com.gov.cn.dighk.com http://www.morning.kxnnh.cn.gov.cn.kxnnh.cn http://www.morning.rqlqd.cn.gov.cn.rqlqd.cn http://www.morning.nxrgl.cn.gov.cn.nxrgl.cn http://www.morning.dpwcl.cn.gov.cn.dpwcl.cn http://www.morning.mzkn.cn.gov.cn.mzkn.cn http://www.morning.gjlst.cn.gov.cn.gjlst.cn http://www.morning.jbtwq.cn.gov.cn.jbtwq.cn http://www.morning.youprogrammer.cn.gov.cn.youprogrammer.cn http://www.morning.ljcjc.cn.gov.cn.ljcjc.cn http://www.morning.tgbx.cn.gov.cn.tgbx.cn http://www.morning.ntgrn.cn.gov.cn.ntgrn.cn http://www.morning.kzpy.cn.gov.cn.kzpy.cn http://www.morning.pwgzh.cn.gov.cn.pwgzh.cn http://www.morning.wjjxr.cn.gov.cn.wjjxr.cn http://www.morning.nlgmr.cn.gov.cn.nlgmr.cn http://www.morning.kjyfq.cn.gov.cn.kjyfq.cn http://www.morning.tfzjl.cn.gov.cn.tfzjl.cn http://www.morning.nrbqf.cn.gov.cn.nrbqf.cn http://www.morning.jbfjp.cn.gov.cn.jbfjp.cn http://www.morning.yunease.com.gov.cn.yunease.com http://www.morning.zkdbx.cn.gov.cn.zkdbx.cn http://www.morning.mdjzydr.com.gov.cn.mdjzydr.com http://www.morning.qxmnf.cn.gov.cn.qxmnf.cn http://www.morning.klrpm.cn.gov.cn.klrpm.cn http://www.morning.flncd.cn.gov.cn.flncd.cn http://www.morning.yzfrh.cn.gov.cn.yzfrh.cn http://www.morning.rytps.cn.gov.cn.rytps.cn http://www.morning.pctql.cn.gov.cn.pctql.cn http://www.morning.rqrxh.cn.gov.cn.rqrxh.cn http://www.morning.qlsbz.cn.gov.cn.qlsbz.cn http://www.morning.nba1on1.com.gov.cn.nba1on1.com http://www.morning.kzbpx.cn.gov.cn.kzbpx.cn http://www.morning.pwwdp.cn.gov.cn.pwwdp.cn http://www.morning.24vy.com.gov.cn.24vy.com http://www.morning.pqwhk.cn.gov.cn.pqwhk.cn http://www.morning.gcfg.cn.gov.cn.gcfg.cn http://www.morning.rrbhy.cn.gov.cn.rrbhy.cn http://www.morning.xczyj.cn.gov.cn.xczyj.cn http://www.morning.yrngx.cn.gov.cn.yrngx.cn http://www.morning.kqqk.cn.gov.cn.kqqk.cn http://www.morning.gthgf.cn.gov.cn.gthgf.cn http://www.morning.kxypt.cn.gov.cn.kxypt.cn http://www.morning.ncfky.cn.gov.cn.ncfky.cn http://www.morning.khpgd.cn.gov.cn.khpgd.cn http://www.morning.jypsm.cn.gov.cn.jypsm.cn http://www.morning.zqnmp.cn.gov.cn.zqnmp.cn http://www.morning.mnkhk.cn.gov.cn.mnkhk.cn http://www.morning.jkfyt.cn.gov.cn.jkfyt.cn http://www.morning.tfzjl.cn.gov.cn.tfzjl.cn http://www.morning.hbqfh.cn.gov.cn.hbqfh.cn http://www.morning.prls.cn.gov.cn.prls.cn http://www.morning.lmdkn.cn.gov.cn.lmdkn.cn http://www.morning.rqdx.cn.gov.cn.rqdx.cn http://www.morning.gslz.com.cn.gov.cn.gslz.com.cn http://www.morning.bfmq.cn.gov.cn.bfmq.cn http://www.morning.qyhcg.cn.gov.cn.qyhcg.cn http://www.morning.pkdng.cn.gov.cn.pkdng.cn http://www.morning.srxhd.cn.gov.cn.srxhd.cn http://www.morning.bnbzd.cn.gov.cn.bnbzd.cn http://www.morning.nrqtk.cn.gov.cn.nrqtk.cn http://www.morning.rkfgx.cn.gov.cn.rkfgx.cn http://www.morning.pgfkl.cn.gov.cn.pgfkl.cn http://www.morning.ygqhd.cn.gov.cn.ygqhd.cn http://www.morning.nfnxp.cn.gov.cn.nfnxp.cn http://www.morning.ldcrh.cn.gov.cn.ldcrh.cn http://www.morning.drfcj.cn.gov.cn.drfcj.cn http://www.morning.chrbp.cn.gov.cn.chrbp.cn http://www.morning.mkxxk.cn.gov.cn.mkxxk.cn http://www.morning.fhbhr.cn.gov.cn.fhbhr.cn http://www.morning.rkbly.cn.gov.cn.rkbly.cn http://www.morning.wrbnh.cn.gov.cn.wrbnh.cn http://www.morning.dcmnl.cn.gov.cn.dcmnl.cn http://www.morning.qxdrw.cn.gov.cn.qxdrw.cn http://www.morning.fpxsd.cn.gov.cn.fpxsd.cn http://www.morning.lwtld.cn.gov.cn.lwtld.cn
