内存不足问题

主讲：张义目录0102内存不足问题Spark和JVM垃圾回收内存不足问题1内存不足问题在有的情况下，当试图使用hdfsdfs-ls命令列出HDFS上一个目录下的所有文件时，会遇到内存溢出（OOM）问题:java.lang.OutOfMemoryError:Javaheapspace或者会看到如下的错误:Exceptioninthread“main”java.lang.OutOfMemoryError:Javaheapspace内存不足问题atjava.util.Arrays.copyof(Arrays.java:2367)atjava.lang.AbstractstringBuilder.expandCapacity(AbstractStringBuilder.java:130)atjava.lang.AbstractstringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114)at...内存不足问题这是因为，当试图列出一个包含大量对象的目录的所有内容时，HDFS客户端的默认的246MB堆内存显得过小了。可以通过为堆内存设置更高的值来提高Hadoop客户端的堆内存大小，如下所示:HADOOP_HEAPSIZE=1024hdfsdfs-ls/user/samHadoop客户端现在拥有了更大的Java堆内存，可以应付对HDFS目录内容的检索。内存不足问题下面是另外一个因OOM导致Spark作业崩溃的例子:ERRORExecutor:Exceptionintask25.0instage16.0(TID999)java.lang.OutOfMemoryError:GCoverheadlimitexceededResolution:spark.executor.memory:Amountofmemorytouseperexecutorprocess,inthesameformatasJVMmemorystrings.该例子中给出了问题及问题解决方案!需要通过提高spark.executor.memory配置参数的值来增大执行器的内存，如第19章所述。Spark和JVM垃圾回收2Spark和JVM垃圾回收Spark应用程序使用100GB以及更高的堆内存空间是不常见的。在Spark环境中，JVM的垃圾回收机制引起的暂停和崩溃是一个常见的需要关注的问题。Spark和JVM垃圾回收Java应用程序中常用的标准垃圾回收策略是并发标记扫描(CMS）和老年代并行(ParallelOld）回收策略。CMS回收策略着重于低延迟，ParallelOld回收策略着重于更高的吞吐量。两种回收策略都曾被证明是可能的性能瓶颈——CMS垃圾回收不执行任何的压缩，而ParallelOld垃圾回收只执行整个堆的压缩，这会引起较长时间的停顿，从而影响应用的性能。如果应用程序要求实时响应，则通常情况下CMS垃圾回收策略是比较好的选择;如果应用程序更偏向于批处理分析，则可以使用ParallelOld垃圾回收策略。Spark和JVM垃圾回收由于Spark兼具流式与批处理的双重功能，因此可以考虑在Hotspot的2.6版本JVM中引入的更新的Garbage-First(G1GC)垃圾回收器。G1垃圾回收器最终会取代CMS垃圾回收器，其目标是同时提供低延迟与高吞吐。Spark和JVM垃圾回收无论采用何种GC回收策略，最关键的仍然是通过减少中间对象的创建或复制、长时间运行对象的堆外存放，以及限制超大对象的创建等来优化内存的使用。Spark和JVM垃圾回收在给一个执行器分配的内存中，75%用于存储和执行。如果不需要很多内存来存储RDD，则可以通过设置spark.storage.mem