oom 订阅
OOM - Out of Mana法力耗尽。出自于游戏魔兽中的一种描述。 展开全文
OOM - Out of Mana法力耗尽。出自于游戏魔兽中的一种描述。
信息
外文名
OOM
出    处
魔兽世界
释    义
法力耗尽
全    称
Out of Mana, Out of Memory等
OOM出处
魔兽世界人们通常用这句话提醒其他队员他已经没有法力不能再施放法术了,特别是治疗魔法。
收起全文
精华内容
参与话题
问答
  • OOM

    千次阅读 2019-01-22 16:38:16
    OOM问题总结什么是OOM为什么会OOMOOM的类型OOM处理方式 什么是OOM OOM ,全称"OutOfMemery",中文名称“内存不够用”。 很长时间以来,很多人都知道jvm内存调优是java知识中的重要组成部分,但是缺乏应用...

    什么是OOM

    OOM ,全称"OutOfMemery",中文名称“内存不够用”。
    很长时间以来,很多人都知道jvm内存调优是java知识中的重要组成部分,但是缺乏应用经验,不知道jvm的使用场景是什么,OOM就是其中一个典型应用场景。

    为什么会OOM

    内存不够用,要么是因为内存太小,要么是因为内存使用不充分
    1.jvm内存分配不够,电脑内存的大小,不等于java程序能够使用的内存大小。jvm分配的内存大小,可以在JVM启动时,通过配置文件配置。
    2.内存利用不当,有两个表现,内存泄漏和内存溢出。

    内存泄漏,对象使用完毕后,不能够及时销毁,变成内存垃圾,如果不能够及时清理,内存垃圾越来越多,可用内存越来越少,影响程序的健康运行。虽然java提供GC机制,可以自动进行内存回收,但是逻辑错误,可能导致垃圾堆积过多。如,将太多的局部作用的对象保存为全局对象。
    内存溢出,请求分配的内存,比jvm剩余可用内存少,导致程序不能够正确运行,导致崩坏。

    OOM的类型

    OOM的类型和jvm运行时数据区的划分有着直接关系,jvm运行时,会管理以下内存区域:
    1.程序计数器,线程私有,用来记录线程当前执行的字节码的行号
    2.jvm栈,线程私有,用来存储基本类型的数据。以函数栈为例,函数执行时,分配函数栈用于存储基本类型数据,函数执行结束后销毁。
    3.堆(heap),所有线程共有(线程通信问题的根源),类实例化后生成的对象,一般保存到堆里面。
    4.方法区,存储类信息,final常量,类中的静态常量,为所有线程共享
    5.运行时常量池,是方法区的一部分,保存常量信息,方法和对象的引用信息等
    6.本地方法栈,native方法,java应用非java代码,使用的内存。
    7.直接内存,非jvm运行时数据区的一部分,可以直接访问的内存,例如NIO中用到的情况。
    按照JVM规范,除了程序计数器不会抛出OOM外,其他各个内存区域都可能会抛出OOM。
    最常见的OOM情况有以下三种:
    1.java.lang.OutOfMemoryError: Java heap space ------>java堆内存溢出,此种情况最常见,一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露,需要通过内存监控软件查找程序中的泄露代码,而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。
    2.java.lang.OutOfMemoryError: PermGen space ------>java永久代溢出,即方法区溢出了,一般出现于大量Class或者jsp页面,或者采用cglib等反射机制的情况,因为上述情况会产生大量的Class信息存储于方法区。此种情况可以通过更改方法区的大小来解决,使用类似-XX:PermSize=64m -XX:MaxPermSize=256m的形式修改。另外,过多的常量尤其是字符串也会导致方法区溢出。
    3.java.lang.StackOverflowError ------> 不会抛OOM error,但也是比较常见的Java内存溢出。JAVA虚拟机栈溢出,一般是由于程序中存在死循环或者深度递归调用造成的,栈大小设置太小也会出现此种溢出。可以通过虚拟机参数-Xss来设置栈的大小。

    OOM处理方式

    1.heapdump
    要dump堆的内存镜像,可以采用如下两种方式:

    • 设置JVM参数-XX:+HeapDumpOnOutOfMemoryError,设定当发生OOM时自动dump出堆信息。不过该方法需要JDK5以上版本。(事先设定好)
    • 使用JDK自带的jmap命令。"jmap -dump:format=b,file=heap.bin " 其中pid可以通过jps获取。(事后dump)

    2.分析原因
    dump堆内存信息后,需要对dump出的文件进行分析,从而找到OOM的原因。常用的工具有:

    • mat: eclipse memory analyzer, 基于eclipse RCP的内存分析工具。
    • jhat:JDK自带的java heap analyze tool,可以将堆中的对象以html的形式显示出来,包括对象的数量,大小等等,并支持对象查询语言OQL,分析相关的应用后,可以通过http://localhost:7000来访问分析结果。不推荐使用,因为在实际的排查过程中,一般是先在生产环境 dump出文件来,然后拉到自己的开发机器上分析,所以,不如采用高级的分析工具比如前面的mat来的高效。
    展开全文
  • oom

    2017-10-19 16:11:04
    最近查找了很多关于OOM,甚至于Java内存管理以及JVM的相关资料,发现这方面的东西太多了,竟有一种眼花缭乱的感觉,要想了解全面的话,恐非一篇文章能说清的,因此按照自己的理解整理了一篇,剩下的还需要继续学习。...

    最近查找了很多关于OOM,甚至于Java内存管理以及JVM的相关资料,发现这方面的东西太多了,竟有一种眼花缭乱的感觉,要想了解全面的话,恐非一篇文章能说清的,因此按照自己的理解整理了一篇,剩下的还需要继续学习。

    1)什么是OOM? OOM,全称“Out Of Memory”,翻译成中文就是“内存用完了”,来源于java.lang.OutOfMemoryError。看下关于的官方说明: Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector. 意思就是说,当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时,就会抛出这个error(注:非exception,因为这个问题已经严重到不足以被应用处理)。

     
    2)为什么会OOM?
     
    为什么会没有内存了呢?原因不外乎有两点:
     
    1)分配的少了:比如虚拟机本身可使用的内存(一般通过启动时的VM参数指定)太少。
     
    2)应用用的太多,并且用完没释放,浪费了。此时就会造成内存泄露或者内存溢出。
     
    内存泄露:申请使用完的内存没有释放,导致虚拟机不能再次使用该内存,此时这段内存就泄露了,因为申请者不用了,而又不能被虚拟机分配给别人用。
    内存溢出:申请的内存超出了JVM能提供的内存大小,此时称之为溢出。
     
    在之前没有垃圾自动回收的日子里,比如C语言和C++语言,我们必须亲自负责内存的申请与释放操作,如果申请了内存,用完后又忘记了释放,比如C++中的new了但是没有delete,那么就可能造成内存泄露。偶尔的内存泄露可能不会造成问题,而大量的内存泄露可能会导致内存溢出。
     
    而在Java语言中,由于存在了垃圾自动回收机制,所以,我们一般不用去主动释放不用的对象所占的内存,也就是理论上来说,是不会存在“内存泄露”的。但是,如果编码不当,比如,将某个对象的引用放到了全局的Map中,虽然方法结束了,但是由于垃圾回收器会根据对象的引用情况来回收内存,导致该对象不能被及时的回收。如果该种情况出现次数多了,就会导致内存溢出,比如系统中经常使用的缓存机制。Java中的内存泄露,不同于C++中的忘了delete,往往是逻辑上的原因泄露。
     
    3)OOM的类型
     
    JVM内存模型:
     
    按照JVM规范,JAVA虚拟机在运行时会管理以下的内存区域:
    • 程序计数器:当前线程执行的字节码的行号指示器,线程私有
    • JAVA虚拟机栈:Java方法执行的内存模型,每个Java方法的执行对应着一个栈帧的进栈和出栈的操作。
    • 本地方法栈:类似“ JAVA虚拟机栈 ”,但是为native方法的运行提供内存环境。
    • JAVA堆:对象内存分配的地方,内存垃圾回收的主要区域,所有线程共享。可分为新生代,老生代。
    • 方法区:用于存储已经被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。Hotspot中的“永久代”。
    • 运行时常量池:方法区的一部分,存储常量信息,如各种字面量、符号引用等。
    • 直接内存:并不是JVM运行时数据区的一部分, 可直接访问的内存, 比如NIO会用到这部分。
    按照JVM规范,除了程序计数器不会抛出OOM外,其他各个内存区域都可能会抛出OOM。
     
    最常见的OOM情况有以下三种:
    • java.lang.OutOfMemoryError: Java heap space ------>java堆内存溢出,此种情况最常见,一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露,需要通过内存监控软件查找程序中的泄露代码,而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。
    • java.lang.OutOfMemoryError: PermGen space ------>java永久代溢出,即方法区溢出了,一般出现于大量Class或者jsp页面,或者采用cglib等反射机制的情况,因为上述情况会产生大量的Class信息存储于方法区。此种情况可以通过更改方法区的大小来解决,使用类似-XX:PermSize=64m -XX:MaxPermSize=256m的形式修改。另外,过多的常量尤其是字符串也会导致方法区溢出。
    • java.lang.StackOverflowError ------> 不会抛OOM error,但也是比较常见的Java内存溢出。JAVA虚拟机栈溢出,一般是由于程序中存在死循环或者深度递归调用造成的,栈大小设置太小也会出现此种溢出。可以通过虚拟机参数-Xss来设置栈的大小。
    4)OOM分析--heapdump
     
    要dump堆的内存镜像,可以采用如下两种方式:
    • 设置JVM参数-XX:+HeapDumpOnOutOfMemoryError,设定当发生OOM时自动dump出堆信息。不过该方法需要JDK5以上版本。
    • 使用JDK自带的jmap命令。"jmap -dump:format=b,file=heap.bin <pid>"   其中pid可以通过jps获取。
    dump堆内存信息后,需要对dump出的文件进行分析,从而找到OOM的原因。常用的工具有:
    • mat: eclipse memory analyzer, 基于eclipse RCP的内存分析工具。详细信息参见:http://www.eclipse.org/mat/,推荐使用。   
    • jhat:JDK自带的java heap analyze tool,可以将堆中的对象以html的形式显示出来,包括对象的数量,大小等等,并支持对象查询语言OQL,分析相关的应用后,可以通过http://localhost:7000来访问分析结果。不推荐使用,因为在实际的排查过程中,一般是先在生产环境 dump出文件来,然后拉到自己的开发机器上分析,所以,不如采用高级的分析工具比如前面的mat来的高效。
    这个链接:http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html中提供了一个采用mat分析的例子 。
     
    注意:因为JVM规范没有对dump出的文件的格式进行定义,所以不同的虚拟机产生的dump文件并不是一样的。在分析时,需要针对不同的虚拟机的输出采用不同的分析工具(当然,有的工具可以兼容多个虚拟机的格式)。IBM HeapAnalyzer也是分析heap的一个常用的工具。
     
    5)小结
     
    涉及到的虚拟机的技术或者工具,往往需要考虑到虚拟机规范以及不同的虚拟机实现。尤其是针对虚拟机调优时,往往需要针对虚拟机在某些方面的实现策略来考虑,比如,不同的虚拟机的垃圾回收算法是不一样的,而这直接影响了虚拟机某些参数的设置,以达到虚拟机的最佳性能。
    而针对JVM运行时的分析与诊断,则需要掌握分析基本方法,针对具体情况,运用虚拟机的原理,具体分析。一句话,水很深啊。

    http://www.cnblogs.com/gaojing/archive/2012/10/30/2844938.html
    展开全文
  • 我们在编写Android程序的时候经常要用到...大家应该知道,我们编写的应用程序都是有一定内存限制的,程序占用了过高的内存就容易出现OOM(OutOfMemory)异常。我们可以通过下面的代码看出每个应用程序最高可用内存是多少

    转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/9316683


    本篇文章主要内容来自于Android Doc,我翻译之后又做了些加工,英文好的朋友也可以直接去读原文。


    http://developer.android.com/training/displaying-bitmaps/index.html


    高效加载大图片


    我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状、不同的大小,但在大多数情况下,这些图片都会大于我们程序所需要的大小。比如说系统图片库里展示的图片大都是用手机摄像头拍出来的,这些图片的分辨率会比我们手机屏幕的分辨率高得多。大家应该知道,我们编写的应用程序都是有一定内存限制的,程序占用了过高的内存就容易出现OOM(OutOfMemory)异常。我们可以通过下面的代码看出每个应用程序最高可用内存是多少。
    int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
    Log.d("TAG", "Max memory is " + maxMemory + "KB");

    因此在展示高分辨率图片的时候,最好先将图片进行压缩。压缩后的图片大小应该和用来展示它的控件大小相近,在一个很小的ImageView上显示一张超大的图片不会带来任何视觉上的好处,但却会占用我们相当多宝贵的内存,而且在性能上还可能会带来负面影响。下面我们就来看一看,如何对一张大图片进行适当的压缩,让它能够以最佳大小显示的同时,还能防止OOM的出现。


    BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于创建Bitmap对象,我们应该根据图片的来源选择合适的方法。比如SD卡中的图片可以使用decodeFile方法,网络上的图片可以使用decodeStream方法,资源文件中的图片可以使用decodeResource方法。这些方法会尝试为已经构建的bitmap分配内存,这时就会很容易导致OOM出现。为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数,将这个参数的inJustDecodeBounds属性设置为true就可以让解析方法禁止为bitmap分配内存,返回值也不再是一个Bitmap对象,而是null。虽然Bitmap是null了,但是BitmapFactory.Options的outWidth、outHeight和outMimeType属性都会被赋值。这个技巧让我们可以在加载图片之前就获取到图片的长宽值和MIME类型,从而根据情况对图片进行压缩。如下代码所示:

    BitmapFactory.Options options = new BitmapFactory.Options();
    options.inJustDecodeBounds = true;
    BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
    int imageHeight = options.outHeight;
    int imageWidth = options.outWidth;
    String imageType = options.outMimeType;

    为了避免OOM异常,最好在解析每张图片的时候都先检查一下图片的大小,除非你非常信任图片的来源,保证这些图片都不会超出你程序的可用内存。


    现在图片的大小已经知道了,我们就可以决定是把整张图片加载到内存中还是加载一个压缩版的图片到内存中。以下几个因素是我们需要考虑的:

    • 预估一下加载整张图片所需占用的内存。
    • 为了加载这一张图片你所愿意提供多少内存。
    • 用于展示这张图片的控件的实际大小。
    • 当前设备的屏幕尺寸和分辨率。


    比如,你的ImageView只有128*96像素的大小,只是为了显示一张缩略图,这时候把一张1024*768像素的图片完全加载到内存中显然是不值得的。


    那我们怎样才能对图片进行压缩呢?通过设置BitmapFactory.Options中inSampleSize的值就可以实现。比如我们有一张2048*1536像素的图片,将inSampleSize的值设置为4,就可以把这张图片压缩成512*384像素。原本加载这张图片需要占用13M的内存,压缩后就只需要占用0.75M了(假设图片是ARGB_8888类型,即每个像素点占用4个字节)。下面的方法可以根据传入的宽和高,计算出合适的inSampleSize值:

    public static int calculateInSampleSize(BitmapFactory.Options options,
    		int reqWidth, int reqHeight) {
    	// 源图片的高度和宽度
    	final int height = options.outHeight;
    	final int width = options.outWidth;
    	int inSampleSize = 1;
    	if (height > reqHeight || width > reqWidth) {
    		// 计算出实际宽高和目标宽高的比率
    		final int heightRatio = Math.round((float) height / (float) reqHeight);
    		final int widthRatio = Math.round((float) width / (float) reqWidth);
    		// 选择宽和高中最小的比率作为inSampleSize的值,这样可以保证最终图片的宽和高
    		// 一定都会大于等于目标的宽和高。
    		inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
    	}
    	return inSampleSize;
    }
    使用这个方法,首先你要将BitmapFactory.Options的inJustDecodeBounds属性设置为true,解析一次图片。然后将BitmapFactory.Options连同期望的宽度和高度一起传递到到calculateInSampleSize方法中,就可以得到合适的inSampleSize值了。之后再解析一次图片,使用新获取到的inSampleSize值,并把inJustDecodeBounds设置为false,就可以得到压缩后的图片了。
    public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
            int reqWidth, int reqHeight) {
    	// 第一次解析将inJustDecodeBounds设置为true,来获取图片大小
        final BitmapFactory.Options options = new BitmapFactory.Options();
        options.inJustDecodeBounds = true;
        BitmapFactory.decodeResource(res, resId, options);
        // 调用上面定义的方法计算inSampleSize值
        options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
        // 使用获取到的inSampleSize值再次解析图片
        options.inJustDecodeBounds = false;
        return BitmapFactory.decodeResource(res, resId, options);
    }
    下面的代码非常简单地将任意一张图片压缩成100*100的缩略图,并在ImageView上展示。
    mImageView.setImageBitmap(
        decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));


    使用图片缓存技术


    在你应用程序的UI界面加载一张图片是一件很简单的事情,但是当你需要在界面上加载一大堆图片的时候,情况就变得复杂起来。在很多情况下,(比如使用ListView, GridView 或者 ViewPager 这样的组件),屏幕上显示的图片可以通过滑动屏幕等事件不断地增加,最终导致OOM。


    为了保证内存的使用始终维持在一个合理的范围,通常会把被移除屏幕的图片进行回收处理。此时垃圾回收器也会认为你不再持有这些图片的引用,从而对这些图片进行GC操作。用这种思路来解决问题是非常好的,可是为了能让程序快速运行,在界面上迅速地加载图片,你又必须要考虑到某些图片被回收之后,用户又将它重新滑入屏幕这种情况。这时重新去加载一遍刚刚加载过的图片无疑是性能的瓶颈,你需要想办法去避免这个情况的发生。


    这个时候,使用内存缓存技术可以很好的解决这个问题,它可以让组件快速地重新加载和处理图片。下面我们就来看一看如何使用内存缓存技术来对图片进行缓存,从而让你的应用程序在加载很多图片的时候可以提高响应速度和流畅性。


    内存缓存技术对那些大量占用应用程序宝贵内存的图片提供了快速访问的方法。其中最核心的类是LruCache (此类在android-support-v4的包中提供) 。这个类非常适合用来缓存图片,它的主要算法原理是把最近使用的对象用强引用存储在 LinkedHashMap 中,并且把最近最少使用的对象在缓存值达到预设定值之前从内存中移除。


    在过去,我们经常会使用一种非常流行的内存缓存技术的实现,即软引用或弱引用 (SoftReference or WeakReference)。但是现在已经不再推荐使用这种方式了,因为从 Android 2.3 (API Level 9)开始,垃圾回收器会更倾向于回收持有软引用或弱引用的对象,这让软引用和弱引用变得不再可靠。另外,Android 3.0 (API Level 11)中,图片的数据会存储在本地的内存当中,因而无法用一种可预见的方式将其释放,这就有潜在的风险造成应用程序的内存溢出并崩溃。


    为了能够选择一个合适的缓存大小给LruCache, 有以下多个因素应该放入考虑范围内,例如:

    • 你的设备可以为每个应用程序分配多大的内存?
    • 设备屏幕上一次最多能显示多少张图片?有多少图片需要进行预加载,因为有可能很快也会显示在屏幕上?
    • 你的设备的屏幕大小和分辨率分别是多少?一个超高分辨率的设备(例如 Galaxy Nexus) 比起一个较低分辨率的设备(例如 Nexus S),在持有相同数量图片的时候,需要更大的缓存空间。
    • 图片的尺寸和大小,还有每张图片会占据多少内存空间。
    • 图片被访问的频率有多高?会不会有一些图片的访问频率比其它图片要高?如果有的话,你也许应该让一些图片常驻在内存当中,或者使用多个LruCache 对象来区分不同组的图片。
    • 你能维持好数量和质量之间的平衡吗?有些时候,存储多个低像素的图片,而在后台去开线程加载高像素的图片会更加的有效。


    并没有一个指定的缓存大小可以满足所有的应用程序,这是由你决定的。你应该去分析程序内存的使用情况,然后制定出一个合适的解决方案。一个太小的缓存空间,有可能造成图片频繁地被释放和重新加载,这并没有好处。而一个太大的缓存空间,则有可能还是会引起 java.lang.OutOfMemory 的异常。


    下面是一个使用 LruCache 来缓存图片的例子:

    private LruCache<String, Bitmap> mMemoryCache;
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
    	// 获取到可用内存的最大值,使用内存超出这个值会引起OutOfMemory异常。
    	// LruCache通过构造函数传入缓存值,以KB为单位。
    	int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
    	// 使用最大可用内存值的1/8作为缓存的大小。
    	int cacheSize = maxMemory / 8;
    	mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
    		@Override
    		protected int sizeOf(String key, Bitmap bitmap) {
    			// 重写此方法来衡量每张图片的大小,默认返回图片数量。
    			return bitmap.getByteCount() / 1024;
    		}
    	};
    }
    
    public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
    	if (getBitmapFromMemCache(key) == null) {
    		mMemoryCache.put(key, bitmap);
    	}
    }
    
    public Bitmap getBitmapFromMemCache(String key) {
    	return mMemoryCache.get(key);
    }
    在这个例子当中,使用了系统分配给应用程序的八分之一内存来作为缓存大小。在中高配置的手机当中,这大概会有4兆(32/8)的缓存空间。一个全屏幕的 GridView 使用4张 800x480分辨率的图片来填充,则大概会占用1.5兆的空间(800*480*4)。因此,这个缓存大小可以存储2.5页的图片。
    当向 ImageView 中加载一张图片时,首先会在 LruCache 的缓存中进行检查。如果找到了相应的键值,则会立刻更新ImageView ,否则开启一个后台线程来加载这张图片。
    public void loadBitmap(int resId, ImageView imageView) {
    	final String imageKey = String.valueOf(resId);
    	final Bitmap bitmap = getBitmapFromMemCache(imageKey);
    	if (bitmap != null) {
    		imageView.setImageBitmap(bitmap);
    	} else {
    		imageView.setImageResource(R.drawable.image_placeholder);
    		BitmapWorkerTask task = new BitmapWorkerTask(imageView);
    		task.execute(resId);
    	}
    }
    BitmapWorkerTask 还要把新加载的图片的键值对放到缓存中。
    class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
    	// 在后台加载图片。
    	@Override
    	protected Bitmap doInBackground(Integer... params) {
    		final Bitmap bitmap = decodeSampledBitmapFromResource(
    				getResources(), params[0], 100, 100);
    		addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
    		return bitmap;
    	}
    }

    掌握了以上两种方法,不管是要在程序中加载超大图片,还是要加载大量图片,都不用担心OOM的问题了!不过仅仅是理论地介绍不知道大家能不能完全理解,在后面的文章中我会演示如何在实际程序中灵活运用上述技巧来避免程序OOM,感兴趣的朋友请继续阅读 Android照片墙应用实现,再多的图片也不怕崩溃 


    关注我的技术公众号,每天都有优质技术文章推送。关注我的娱乐公众号,工作、学习累了的时候放松一下自己。

    微信扫一扫下方二维码即可关注:

            

    展开全文
  • oom diagnostic logging

    2020-12-02 14:35:38
    <div><p>Disable the oom killer for a container's memory cgroup when the memory limit is set. If oom occurs later, the problem task (that is, the one which triggered oom) will be suspended ([1]) ...
  • 前面一节重点分享了Linux的内存分配策略,基于上述的分配策略,为了规避超售的风险,Linux采了一种OOM Killer的机制,即系统可用内存(包括Swap)即将使用完之前,选择性的Kill掉一些进程以求释放一些内存
  • Low memory is not OOM

    2020-11-28 00:24:09
    <p>In normal operation, earlyoom should not occur at all OOM, since preventing OOM is the main task of earlyoom, not a reaction to OOM that has already occurred. <p>What about replace "Out of ...
  • OOM Killer

    千次阅读 2011-08-12 16:29:30
    OOM Killer The functions, code excerpts and comments discussed below here are from mm/oom_kill.c unless otherwise noted. It is

    OOM Killer

     
     The functions, code excerpts and comments discussed below here are from mm/oom_kill.c unless otherwise noted.

    It is the job of the linux 'oom killer' to sacrifice one or more processes in order to free up memory for the system when all else fails. It will also kill any process sharing the same mm_struct as the selected process, for obvious reasons. Any particular process leader may be immunized against the oom killer if the value of its /proc/<pid>/oomadj is set to the constant OOM_DISABLE (currently defined as -17).

    The function which does the actual scoring of a process in the effort to find the best candidate for elimination is called badness(), which results from the following call chain:


    _alloc_pages -> out_of_memory() -> select_bad_process() -> badness()

     

    The comments to badness() pretty well speak for themselves:

    /*
     * oom_badness - calculate a numeric value for how bad this task has been
     * @p: task struct of which task we should calculate
     * @p: current uptime in seconds
     *
     * The formula used is relatively simple and documented inline in the
     * function. The main rationale is that we want to select a good task
     * to kill when we run out of memory.
     *
     * Good in this context means that:
     * 1) we lose the minimum amount of work done
     * 2) we recover a large amount of memory
     * 3) we don't kill anything innocent of eating tons of memory
     * 4) we want to kill the minimum amount of processes (one)
     * 5) we try to kill the process the user expects us to kill, this
     *    algorithm has been meticulously tuned to meet the principle
     *    of least surprise ... (be careful when you change it)
     */

     

      badness() works by accumulating 'points' for each process it examines and returning them to select_bad_process(). The process with the highest number of points, loses and is ultimately eliminated, unless it is already in the midst of freeing up memory on its own.

    The scoring of a process starts with the size of its resident memory:

           

            /*
             * The memory size of the process is the basis for the badness.
             */
            points = p->mm->total_vm;

     The independent memory size of any child (except a kernel thread) is added to the score:
     

            /*
             * Processes which fork a lot of child processes are likely
             * a good choice. We add the vmsize of the childs if they
             * have an own mm. This prevents forking servers to flood the
             * machine with an endless amount of childs
             */
              ...
                      if (chld->mm != p->mm && chld->mm)
                            points += chld->mm->total_vm;

     

     'Niced' processes have their scores increased, and long running processes have their scores decreased:
           

            s = int_sqrt(cpu_time);
            if (s)
                    points /= s;
            s = int_sqrt(int_sqrt(run_time));
            if (s)
                    points /= s;
    
            /*
             * Niced processes are most likely less important, so double
             * their badness points.
             */
            if (task_nice(p) > 0)
                    points *= 2;
    


     Processes with CAP_SYS_ADMIN and CAP_SYS_RAWIO, respectively, each have their scores reduced:
           

            /*
             * Superuser processes are usually more important, so we make it
             * less likely that we kill those.
             */
            if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_ADMIN) ||
                                    p->uid == 0 || p->euid == 0)
                    points /= 4;
    
            /*
             * We don't want to kill a process with direct hardware access.
             * Not only could that mess up the hardware, but usually users
             * tend to only have this flag set on applications they think
             * of as important.
             */
            if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO))
                    points /= 4;
    


     Finally the accumulated score is bitshifted by the user-settable value of /proc/<pid>/oomadj:
           

            /*
             * Adjust the score by oomkilladj.
             */
            if (p->oomkilladj) {
                    if (p->oomkilladj > 0)
                            points <<= p->oomkilladj;
                    else
                            points >>= -(p->oomkilladj);
            }


      So the ideal candidate for liquidation is a recently started, non privileged process which together with its children uses lots of memory, has been nice'd, and does no raw I/O. Something like a nohup'd parallel kernel build (which is not a bad choice since all results are saved to disk and very little work is lost when a 'make' is terminated).
     


     

     

    展开全文
  • CUDA OOM issue

    2020-11-21 21:42:30
    <div><p>Hi, I was running the Libri example and got CUDA OOM issue (either 1 or 4 v100 GPU). I tried <code>the --empty-cache-freq</code> flag. It still occurs OOM eventually although it takes longer ...
  • OutOfMemoryError (OOM)解决思路-资料版

    万次阅读 2020-01-14 16:24:08
    我们都知道JVM的内存管理是自动化的,Java语言的程序指针也不需要开发人员手工释放,JVM的GC会自动的进行回收,但是,如果编程不当,JVM仍然会发生内存泄露,导致Java程序产生了 OutOfMemoryError(OOM)错误。 产生...
  • Nov 25 13:34:49 rancher kernel: [4159464.630005] dockbeat invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0 Nov 26 08:50:23 rancher kernel: [4228783.775652] dockbeat invoked oom-...
  • 编译android程序出现OOM

    2015-05-09 03:30:39
    **使用 jdk-7u79-windows-x64,android 5.0.1,IntelliJ IDEA Community Edition 14.0.2编译程序,出现OOM:** Error:Android Dex: java.lang.OutOfMemoryError: GC overhead limit exceeded Error:Android Dex:...
  • <ol><li>Select all toolbars via the View | Toolbars menu.</li><li>Close OOM.</li><li>Open OOM and open a map.</li><li>Observe that all toolbars are deselected again.</li></ol> <h3>Actual behaviour <p>...
  • android 图片转base64 OOM

    2016-08-24 00:56:24
    OOM异常,请问各位大师有什么解决办法? OOM截图: ![图片说明](https://img-ask.csdn.net/upload/201608/24/1471999999_344782.png) private String encode(String path) { Bitmap bitmap = null; bitmap = ...
  • **请教各位大神,我通过CDM自动生成OOM,结果如下(不显示multiplicity):** ![图片说明](https://img-ask.csdn.net/upload/201612/24/1482543855_938656.png) **但是点击去设置association的时候看到是有...
  • Java OOM 类型

    2020-03-05 14:48:26
    1、java.lang.OutOfMemoryError: PermGen space 说明 PermGen space的全称是Permanent Generation space,是指内存的永久保存区域。用于存放Class和Meta的信息,GC(Garbage Collection)不会在主程序运行期对PermGen ...
  • CopyOnWriteArrayList引发OOM

    千次阅读 2011-09-27 14:29:41
    正常一年多的一个服务突然在23号出现异常,响应最快的竟然达到60几秒。...看异常日志,发现竟然有一个新上的Servlet出现OOM。review该Servlet,发现竟然用了一个CopyOnWriteArrayList来存放大量写和读和临时数
  • 現在已經找不到會OOM的問題到底是哪邊了 我們懷疑是 Fragment 換頁時 前幾頁的東西都沒有Finish 想問的是 **如何讓Fragment只保持目前頁面運作 另外三頁都清掉** 現在的HTC ONE 感覺有大量使用Fragment...
  • W c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\core\framework\op_kernel.cc:993] Resource exhausted: OOM when allocating tensor with shape[5,5,32,64] I c:\tf_jenkins\home\...
  • -1000</code> and therefore I keep getting xfce4-notifyd (with 25M VmRSS) killed first which occasionally gets an oom_score value of 1 instead of the process that actually ate all of my ram and ...

空空如也

1 2 3 4 5 ... 20
收藏数 17,907
精华内容 7,162
关键字:

oom