内存溢出

Spark Knowledge NO.2 11.RDD缓存： Spark可以使用 persist 和 cache 方法将任意 RDD 缓存到内存、磁盘文件系统中。缓存是容错的，如果一个 RDD 分片丢失，可以通过构建它的 transformation自动重构。被缓存的 RDD 被使用的时，存取速度会被大大加速。一般的executor内存60%做 cache， 剩下的40%做task。 Spark中，RDD类可以使用cache() 和 persist() 方法来缓存。cache()是persist()的特例，将该RDD缓存到内存中。而persist可以指定一个StorageLevel。StorageLevel的列表可以在StorageLevel 伴生单例对象中找到。 Spark的不同StorageLevel ，目的满足内存使用和CPU效率权衡上的不同需求。我们建议通过以下的步骤来进行选择： 如果你的RDDs可以很好的与默认的存储级别(MEMORY_ONLY)契合，就不需要做任何修改了。这已经是CPU使用效率最高的选项，它使得RDDs的操作尽可能的快。 如果不行，试着使用MEMORY_ONLY_SER并且选择一个快速序列化的库使得对象在有比较高的空间使用率的情况下，依然可以较快被访问。 尽可能不要存储到硬盘上，除非计算数据集的函数，计算量特别大，或者它们过滤了大量的数据。否则

前言 场景：C++通过JNI将数据传输给Java程序 问题：运行一段时间String对象和Char字符不停变大，直到内存溢出（JVM-OOM） 1 过程 Jmap初步分析头部对象内存占用 PS：jmap -histo:live <pid>，执行该方法会同步执行一次GC，所以，展示的都是无法GC的对象。 发现：String对象有28万个，可能存在String对象被长期持有的现象，初步怀疑是HashMap等缓存持有 Jmap导出堆栈分析：导出堆栈时String对象是21万个 jmap -dump:live,format=b,file=/root/edr.bin 17994 用eclipse-mat打开堆栈文件：通过Histogram看看对象实例数 发现：String对象确实是21万个 看看String对象来自于哪里，并将String列表按RetainedHeap倒叙排列 发现：String对象是来自于本地JNI线程，且这个JNI线程还持有大量的内存 查看程序线程内存占用情况 发现：存在10个相似的线程，都占用了很多内存，且线程类型还是守护类型，但是无法通过线程名判断是什么线程对象 查看线程持有哪些对象 发现：线程持有14759个String对象，基本可以判断是该类（10个）线程没有将JNI-String内存释放 最终确认确实是C++JNI相关代码没有释放内存 2 总结

JVM 参数调优： 堆空间主要组成部分： 1：新生代（new generation），新生代又划分为3部分： 1 eden 2 From Survivor（s0区域） 3 To Survivor（s1区域） 其中s0和s1区域大小相等 2：老年代（tenured generation） new出来的对象都会存放在堆内存中 新生代和老年代的存在主要用于垃圾回收机制 ，其中主要针对的是新生代，因为对象首先分配在eden区，在新生代回收后，如果对象还存活，则进入s0或s1区，之后每经过一次新生代回收，如果对象存活则它的年龄就加1，对象达到一定的年龄后，则进入老年代。 JVM调优方案： 相关优化参数 -Xms 堆初始值 -Xmx 堆最大可用值 -Xmn 新生代最大可用值 一般为堆大小的1/3或者1/4 -XX:SurvivorRatio 设置新生代中eden空间和from/to空间的比例 -XX:SurvivorRatio=eden/from=eden/to -XX:NewRatio 设置老年代和新生代比例 -XX:NewRatio=老年代/新生代 思路： 在JVM启动参数中，可以设置跟内存、垃圾回收相关的一些参数设置，默认情况不做任何设置JVM会工作的很好，但对一些配置很好的Server和具体的应用必须仔细调优才能获得最佳性能。通过设置我们希望达到一些目标： 1、GC的时间足够的小 2

Java应用程序是运行在JVM上的，得益于JVM的内存管理和垃圾收集机制，开发人员的效率得到了显著提升，也不容易出现内存溢出和泄漏问题。但正是因为开发人员把内存的控制权交给了JVM，一旦出现内存方面的问题，如果不了解JVM的工作原理，将很难排查错误。本文将从理论角度介绍虚拟机的内存管理和垃圾回收机制，算是入门级的文章，希望对大家的日常开发有所助益。 一、内存管理 也许大家都有过这样的经历，在启动时通过-Xmx或者-XX:MaxPermSize这样的参数来显式的设置应用的堆(Heap)和永久代(Permgen)的内存大小，但为什么不直接设置JVM所占内存的大小，而要分别去设置不同的区域？JVM所管理的内存被分成多少区域？每个区域有什么作用？如何来管理这些区域？ 1.1 运行时数据区 JVM在执行Java程序时会把其所管理的内存划分成多个不同的数据区域，每个区域的创建时间、销毁时间以及用途都各不相同。比如有的内存区域是所有线程共享的，而有的内存区域是线程隔离的。线程隔离的区域就会随着线程的启动和结束而创建和销毁。JVM所管理的内存将会包含以下几个运行时数据区域，如下图的上半部分所示。 Method Area (方法区) 方法区是所有线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、JIT编译后的代码等数据。在Java虚拟机规范中，方法区属于堆的一个逻辑部分

转自： https://www.cnblogs.com/jane4321/p/11012866.html 一、内存泄漏 1、堆内存溢出 现象： 　　（1）压测执行一段时间后，系统处理能力下降。这时用JConsole、JVisualVM等工具连上服务器查看GC情况，每次GC回收都不彻底并且可用堆内存越来越少。 　　（2）压测持续下去，最终在日志中有报错信息：java.lang.OutOfMemoryError.Java heap space。 排查手段： 　　（1）使用jmap -histo pid > test.txt命令将堆内存使用情况保存到test.txt文件中，打开文件查看排在前50的类中有没有熟悉的或者是公司标注的类名，如果有则高度怀疑内存泄漏是这个类导致的。 　　（2）如果没有，则使用命令：jmap -dump:live,format=b,file=test.dump pid生成test.dump文件，然后使用MAT进行分析。 　　（3）如果怀疑是内存泄漏，也可以使用JProfiler连上服务器在开始跑压测，运行一段时间后点击“Mark Current Values”，后续的运行就会显示增量，这时执行一下GC，观察哪个类没有彻底回收，基本就可以判断是这个类导致的内存泄漏。 解决方式：优化代码，对象使用完毕，需要置成null。 2、持久代溢出 现象：压测执行一段时间后

(node.js)webpack打包报javaScript heap out of memory,内存溢出 // 方法一 /** ===https://www.cnblogs.com/yangjing1314/p/9993835.html=== */ FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory 经过搜索，最后的解决方案是删除npmrc文件（不是nodejs安装目录npm模块下的那个npmrc文件，而是C:\Users\{账户}\下的.npmrc文件）。 // 方法二 https://blog.csdn.net/QIANG123___/article/details/79183544 里面有句关键的话，CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory JavaScript堆内存不足，这里说的 JavaScript 其实就是 Node，我们都知道 Node 是基于V8引擎，在一般的后端开发语言中，在基本的内存使用上没有什么限制，但是我去查阅了相关的资料才发现，在 Node 中通过 JavaScript 使用内存时只能使用部分内存

Spark数据倾斜与shuffle调优 1. 数据倾斜原理和现象分析 1.1 数据倾斜概述 有的时候，我们可能会遇到大数据计算中一个最棘手的问题—— 数据倾斜 ，此时Spark作业的性能会比期望差很多。 数据倾斜调优，就是使用各种技术方案解决不同类型的数据倾斜问题，以保证Spark作业的性能。 1.2 数据倾斜发生时的现象 （1）绝大多数task执行得都非常快，但个别task执行极慢 你的大部分的task，都执行的特别快，很快就执行完了，剩下几个task，执行的特别特别慢， 前面的task，一般10s可以执行完5个；最后发现某个task，要执行1个小时，2个小时才能执行完一个task。 这个时候就出现数据倾斜了。 这种方式还算好的，因为虽然老牛拉破车一样，非常慢，但是至少还能跑。 （2）绝大数task执行很快，有的task直接报OOM (Jvm Out Of Memory) 异常 运行的时候，其他task都很快执行完了，也没什么特别的问题；但是有的task，就是会突然间报了一个 OOM ，JVM Out Of Memory，内存溢出了，task failed，task lost，resubmitting task等日志异常信息。反复执行几次都到了某个task就是跑不通，最后就挂掉。 某个task就直接OOM，那么基本上也是因为数据倾斜了，task分配的数量实在是太大了！！

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、问题背景 今天中午开始，几台线上服务器差不多在同个时间段相继挂掉，于是急忙排查故障原因。 二、原因分析 首先使用visualVM看资源使用情况，发现线程有2万多，甚至有的实例超过3万，于是通过jstack命令查看线程堆栈信息，看哪里代码生成太多的线程。 失望的是，只看到线程池名称，但是看不到具体是哪个代码类引起的问题。 于是另一种方式，换个角度，能否看到哪些对象占用空间大。使用jmap -dump命令，结果，生成的内存dump文件有20G，根本无法分析。 后来，同事提醒调小JVM最大使用内存（从30G调整到15G），观察了一段时间没有再出现问题（以为问题解决了，但是线程无限增大，理论上还是会内存溢出，后来发现确实不是这块的问题）。 第二天，又想了下这块原因，我们系统的线程池是公用的，理论上从代码层面产生的线程最多100个，不会更多，为什么会有超过3万？沿着这个思路想到，是否有人没有使用系统的线程池而是自己创建的线程池？ 果然如此，经过搜索，发现有一个接口，调用一次就会创建一个最小线程数为10的线程池，搜了一个这个接口的调用情况，果然是在中午的时候开始高频率的调用，直至晚上8.30结束了调用，这也是调整JVM内存看似解决问题的原因。 三、结论 要慎用线程池，尽量使用公用线程池，这用线程比较可控

一、内存溢出和内存泄露 一种通俗的说法。 1、内存溢出：你申请了10个字节的空间，但是你在这个空间写入11或以上字节的数据，出现溢出。 2、内存泄漏：你用new申请了一块内存，后来很长时间都不再使用了（按理应该释放），但是因为一直被某个或某些实例所持有导致 GC 不能回收，也就是该被释放的对象没有释放。 下面具体介绍。 1.1 内存溢出 java.lang.OutOfMemoryError，是指程序在申请内存时，没有足够的内存空间供其使用，出现OutOfMemoryError。 产生原因 产生该错误的原因主要包括： JVM内存过小。 程序不严密，产生了过多的垃圾。 程序体现 一般情况下，在程序上的体现为： 内存中加载的数据量过于庞大，如一次从数据库取出过多数据。 集合类中有对对象的引用，使用完后未清空，使得JVM不能回收。 代码中存在死循环或循环产生过多重复的对象实体。 使用的第三方软件中的BUG。 启动参数内存值设定的过小。 错误提示 此错误常见的错误提示： tomcat:java.lang.OutOfMemoryError: PermGen space tomcat:java.lang.OutOfMemoryError: Java heap space weblogic:Root cause of ServletException java.lang

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 项目中遇到数据导入、导出用excle操作的问题，数据量在W级别，因03版有6W+的限制，系统统一采用07版excel来做，采用POI进行处理，在导入、导出的时候都遇到的内存溢出的问题，导入方面主要参考下面的文章处理 http://blog.csdn.net/lishengbo/article/details/40711769（感谢作者分享） 导出部分采用官方提供的例子，采用SXSSFWorkbook进行导出。可参考以下文章： http://blog.csdn.net/wangweiyan89/article/details/8863975 单独做这两部分功能都能解决内存溢出的问题，那么问题来了，系统中存在一种操作，需要将导出的文件再次进行导入，这里就是用 SXSSFWorkbook导出的文件在采用SAX解析的方式进行读取，这时出现读不到数据的情况，前一步生成的excel可以正常打开查看，但无法通过程序再次读取，考虑过网络下载文件存在保护视图的等权限的问题，但读的权限是可以的，换思路。。。奇怪的是excel文件打开后，随便点击哪里，不进行修改，再关闭的时候就提示需要保存修改，保存修改后在次用程序读取就可以正常读取数据了。考虑是不是写文件的时候出现差错，用官方提供的最简单例子进行读取，发现同样问题。 。。。