精华内容
下载资源
问答
  • Java OOM问题如何排查

    2021-04-25 21:13:19
    导致OOM问题的原因 为什么会没有内存了呢?原因不外乎有两点: 1)分配的少了:比如虚拟机本身可使用的内存(一般通过启动时的VM参数指定)太少。 2)应用用的太多,并且用完没释放,浪费了。此时就会造成内存泄露...

    什么是OOM

    OOM,全称“Out Of Memory”,翻译成中文就是“内存用完了”。当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时,就会抛出这个error(注:非exception,因为这个问题已经严重到不足以被应用处理)。

    导致OOM问题的原因

    为什么会没有内存了呢?原因不外乎有两点:
    1)分配的少了:比如虚拟机本身可使用的内存(一般通过启动时的VM参数指定)太少。
    2)应用用的太多,并且用完没释放,浪费了。此时就会造成内存泄露或者内存溢出。

    内存溢出

    申请的内存超出了JVM能提供的内存大小,此时称之为溢出。比如: 系统已经不能再分配出你所需要的空间,比如你需要100M的空间,系统只剩90M了,这就叫内存溢出。
    例子
    一个盘子用尽各种方法只能装4个果子,你装了5个,结果掉倒地上不能吃了。这就是溢出。比方说栈,栈满时再做进栈必定产生空间溢出,叫上溢,栈空时再做退栈也产生空间溢出,称为下溢。就是分配的内存不足以放下数据项序列,称为内存溢出。说白了就是我承受不了那么多,那我就报错。
    内存溢出原因

    1. 内存中加载的数据量过于庞大,如一次从数据库取出过多数据;
    2. 集合类中有对对象的引用,使用完后未清空,使得JVM不能回收;
    3. 代码中存在死循环或循环产生过多重复的对象实体;
    4. 启动参数内存值设定的过小

    解决方法

    1. 修改JVM启动参数,直接增加内存。(-Xms,-Xmx参数一定不要忘记加。)
    2. 检查错误日志,查看“OutOfMemory”错误前是否有其 它异常或错误。
    3. 对代码进行走查和分析,找出可能发生内存溢出的位置。
    4. 使用内存查看工具动态查看内存使用情况

    对代码分析找出可能发生内存溢出的位置, 可能出现的几种情况:
    1、检查对数据库查询中,是否有一次获得全部数据的查询。一般来说,如果一次取十万条记录到内存,就可能引起内存溢出。这个问题比较隐蔽,在上线前,数据库中数据较少,不容易出问题,上线后,数据库中数据多了,一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
    2、检查代码中是否有死循环或递归调用
    3、检查是否有大循环重复产生新对象实体
    4、检查List、MAP等集合对象是否有使用完后,未清除的问题。List、MAP等集合对象会始终存有对对象的引用,使得这些对象不能被GC回收。

    内存泄露

    强引用所指向的对象不会被回收,可能导致内存泄漏,虚拟机宁愿抛出OOM也不会去回收他指向的对象。
    意思就是你用资源的时候为他开辟了一段空间,当你用完时忘记释放资源了,这时内存还被占用着,一次没关系,但是内存泄漏次数多了就会导致内存溢出
    例子
    你向系统申请分配内存进行使用(new),可是使用完了以后却不归还(delete),结果你申请到的那块内存你自己也不能再访问(也许你把它的地址给弄丢了),而系统也不能再次将它分配给需要的程序。就相当于你租了个带钥匙的柜子,你存完东西之后把柜子锁上之后,把钥匙丢了或者没有将钥匙还回去,那么结果就是这个柜子将无法供给任何人使用,也无法被垃圾回收器回收,因为找不到他的任何信息。
    分类

    • 常发性内存泄漏。发生内存泄漏的代码会被多次执行到,每次被执行的时候都会导致一块内存泄漏。
    • 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境,偶发性的也许就变成了常发性的。
    • 一次性内存泄漏。发生内存泄漏的代码只会被执行一次。比如,在类的构造函数中分配内存,在析构函数中却没有释放该内存,所以内存泄漏只会发生一次。
    • 隐式内存泄漏。程序在运行过程中不停的分配内存,但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏,因为最终程序释放了所有申请的内存。但是对于一个服务器程序,需要运行几天,几周甚至几个月,不及时释放内存也可能导致最终耗尽系统的所有内存。所以,我们称这类内存泄漏为隐式内存泄漏。

    注意
    一般我们所说的内存泄漏指的是堆内存的泄露,堆内存是指程序从堆中分配的,大小随机的用完后必须显示释放的内存,C++/C中有free函数可以释放内存,java中有垃圾回收机制不用程序员自己手动调用释放。如果这块内存不释放,就不能再用了,这就叫这块内存泄漏了。
    从用户使用程序的角度来看,内存泄漏本身不会产生什么危害,作为一般的用户,根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积,这会最终消耗尽系统所有的内存。从这个角度来说,一次性内存泄漏并没有什么危害,因为它不会堆积,而隐式内存泄漏危害性则非常大,因为较之于常发性和偶发性内存泄漏它更难被检测到。

    最常见的OOM情况有以下三种:

    1. java.lang.OutOfMemoryError: Java heap space ------>java堆内存溢出
      此种情况最常见,一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露,需要通过内存监控软件查找程序中的泄露代码,而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。

    2. java.lang.OutOfMemoryError: PermGen space 或 java.lang.OutOfMemoryError:MetaSpace ------>java方法区(java8 元空间)溢出
      一般出现于大量Class或者jsp页面,或者采用cglib等反射机制的情况,因为上述情况会产生大量的Class信息存储于方法区。此种情况可以通过更改方法区的大小来解决,使用类似-XX:PermSize=64m -XX:MaxPermSize=256m的形式修改。另外,过多的常量尤其是字符串也会导致方法区溢出。

    3. java.lang.StackOverflowError ------> 不会抛OOM error,但也是比较常见的Java内存溢出。JAVA虚拟机栈溢出,一般是由于程序中存在死循环或者深度递归调用造成的,栈大小设置太小也会出现此种溢出。可以通过虚拟机参数-Xss来设置栈的大小。

    排查手段

    涞源:https://editor.csdn.net/md?not_checkout=1&articleId=116138385

    来源:https://www.cnblogs.com/rgever/p/8899758.html

    展开全文
  • 引言一般你去面试的时候,面试官...请你说说出常见的OOM问题?这时的你可能是懵的。先来做个调查,你知道几种常见的OOM呢?欢迎评论区留言。总览来看一下思维导图,这些错误的异常你有遇到过吗?常见的OOM1. Stack...

    f3b000c56ccaae9c8acaa2f7724dae3b.png

    引言

    一般你去面试的时候,面试官经常会问:请谈谈你对OOM的认识?然后,你可能会说OOM就是out of memory,那如果你只是这么答的话,这可不是面试官想要的答案;面试官又接着问,那你生产过程中有遇到哪些OOM呢?请你说说出常见的OOM问题?这时的你可能是懵的。先来做个调查,你知道几种常见的OOM呢?欢迎评论区留言。

    总览

    来看一下思维导图,这些错误的异常你有遇到过吗?

    b04e384cb2d113cf4ea4dbc4bba98b41.png

    常见的OOM

    1. StackOverflowError

    线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常 。递归调用方法,如果没有方法出口的方法会造成StackOverflowError,或者说如果调用的过深都会抛出,这种错误也比较容易定位。

    9902601a891df1c576b7a21ee07b0066.png

    2. java.lang.OutOfMemoryError: Java heap space

    溢出原因:深入理解Java虚拟机书中讲到java堆溢出,Java堆用于存储对象实例,只要不断地创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象,那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。

    3. java.lang.OutOfMemoryError:GC overhead limit exceeded

    GC回收时间长时会抛出OutOfMemoryError。过长的定义是,超过98%的时间用来做GC并且回收了不到2%的堆内存,连续多次GC都只回收了不到2%的极端情况下才会抛出。假设不抛出GC overhead limit错误会发生什么情况呢?那就是GC清理的这么点内存很快会再次填满,迫使GC再次执行,这样就形成恶性循环,CPU使用率一直是100%,而GC缺没有任何成果。

    4. java.lang.OutOfMemoryError:Direct buffer memory

    Direct memory可以通过参数-XX:MaxDirectMemorySize设定本机直接内存可用大小,如果不指定,则默认与java堆内存大小相同。过使用-XX:MaxDirectMemorySize=5M,限制最大可使用的本机直接内存大小为5MB,如果超过将抛出异常。

    5. java.lang.OutOfMemoryError:unable to create new native thread

    不知道你们生产环境是否会出现这种情况,高并发请求服务器时,经常出现如下异常java.lang.OutOfMemoryError:unable to create new native thread。那出现的原因呢?

    1.创建太多的线程了2.服务器的设置限制了你创建线程的数量了6. java.langOutOfMemoryError:Metaspace

    我们知道Java8及以后已经使用Metaspace来替代永久代,Metaspace并不在虚拟机内存中而是使用本地内存。主要还是是加载到内存中的 class 数量太多或者体积太大。这时可以通过JVM参数-XX:MaxMetaspaceSize指定。

    总结

    不知道你们是否学会了呢?现在面试要求越来越高,面试的时候对JVM考察的也越来越多,尤其是jvm的一些异常和调优这块是高频面试题,所以是时候开始Java虚拟机了。

    想了解更多请关注我吧!关注我然后私信我可以获取【深入理解Java虚拟机】网盘地址

    展开全文
  • MySQL OOM问题处理一则

    2021-01-25 15:03:30
    一个游戏业务的MySQL数据库,多台服务器上mysql服务被OOM,但OOM的原因是什么呢?其实导致OOM的直接原因并不复杂,就是因为服务器内存不足,内核需要回收内存,回收内存就是kill掉服务器上使用内存最多的程序,而...

    一个游戏业务的MySQL数据库,多台服务器上mysql服务被OOM,但OOM的原因是什么呢?其实导致OOM的直接原因并不复杂,就是因为服务器内存不足,内核需要回收内存,回收内存就是kill掉服务器上使用内存最多的程序,而mysql服务是使用内存最多,所以就OOM了。

    首先我们检查是什么原因导致内存不足,这台服务器物理内存为64G

    # free -m

    total      used      free    shared    buffers    cached

    Mem:        64375      57821      6553          0        554      16369

    -/+ buffers/cache:      40897      23478

    Swap:        16383          5      16378

    被oom第一个怀疑的原因就是innodb_buffer_pool_size大小设置是否合理

    141205 18:47:57 [Note] Plugin 'FEDERATED' is disabled.

    141205 18:47:57 InnoDB: The InnoDB memory heap is disabled

    141205 18:47:57 InnoDB: Mutexes and rw_locks use GCC atomic builtins

    141205 18:47:57 InnoDB: Compressed tables use zlib 1.2.3

    141205 18:47:57 InnoDB: Using Linux native AIO

    141205 18:47:57 InnoDB: Initializing buffer pool, size = 58.0G

    141205 18:48:04 InnoDB: Completed initialization of buffer pool

    141205 18:48:04 InnoDB: highest supported file format is Barracuda.

    从上面mysql启动的日志中,可以看到在14年mysql启动的时候,innodb_buffer_pool_size设置成了58G,一直到OOM,innodb_buffer_pool_size一直是58G

    一台物理内存为64G的服务器,innodb_buffer_pool_size的这个设置确实有点大

    另一个检查是vm.swappiness的设置

    现在服务器上vm.swappiness设置为0,而RHEL/CentOS 6.4的内核从2.6.32-358这个版本以后,swappiness的行为就已经修改了,

    最新的内核,建议把vm.swappiness设置1

    # uname -r

    2.6.32-431.el6.x86_64

    这里我们系统是最新的内核

    但是通过下面的分析,发现innodb_buffer_pool_size,vm.swappiness两个参数设置的不合理只是OOM中的潜在问题,并不是触发OOM的直接原因

    可以通过show engine innodb status,查看一下mysql内存的使用情况

    .....

    ----------------------

    BUFFER POOL AND MEMORY

    ----------------------

    Total memory allocated 63979913216; in additional pool allocated 0

    Internal hash tables (constant factor + variable factor)

    Adaptive hash index 7893457408      (7887918656 + 5538752)

    Page hash          61625224 (buffer pool 0 only)

    Dictionary cache    247241428      (246498992 + 742436)

    File system        111712  (82672 + 29040)

    Lock system        154077792      (154061624 + 16168)

    Recovery system    0      (0 + 0)

    Dictionary memory allocated 742436

    Buffer pool size        3801087

    Buffer pool size, bytes 62277009408  --Buffer Pool大小

    Free buffers            3686413  --Buffer Pool中有多少个空白页

    Database pages          112368  --Buffer Pool中使用了多少页

    Old database pages      22365

    ........

    这里可以发现Buffer pool中大部分页都是Free的,其实mysql服务并未直接分配到58G的内存。

    通过sar -B,发现了大量的与SWAP内存的交换,而这个频繁交换的时间是每半小时发生一次

    10:00:01 AM  pgpgin/s pgpgout/s  fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff

    10:10:01 AM  24472.34  13779.62  10542.81      0.88  8986.53  1547.25    42.00  1556.45    97.94

    10:20:01 AM    24.55  11989.73  10669.42      0.14  4369.46    138.54      0.11    138.64    100.00

    10:30:01 AM      1.29  8991.32  9832.53      0.01  3596.49    20.53      0.55    21.08    100.00

    10:40:01 AM  24522.56  17124.60  11295.04      0.75  9649.33  1710.20    51.21  1666.83    94.63

    10:50:01 AM      4.68  8691.01  10355.18      0.08  3934.04    21.22      0.11    21.33    100.00

    11:00:01 AM      3.71  10738.47  10384.87      0.09  4017.96    94.24      0.28    94.47    99.96

    11:10:02 AM  24924.74  14603.99  11129.07      0.86  9504.08  1751.06    40.43  1642.30    91.67

    11:20:01 AM    11.95  8548.50  10206.84      0.11  3819.67    48.74      0.11    48.85    100.00

    Average:      8944.00  11658.11  10479.06      0.40  5958.60    687.73    18.04    668.62    94.74

    每半个小时的SWAP内存交换是什么引起的呢?

    [root@tlbb3d_yd_mxy_120-132-43-203_sx ~]# crontab -l

    00 05 * * * /bin/bash /home/databak/scripts/xtrabackup.sh FULL_BACKUP

    */30 * * * * /bin/bash /home/databak/scripts/xtrabackup.sh INCRE_BACKUP

    00 03 * * * /bin/bash /home/databak/dbbbak.sh xxx

    通过crontab 发现,这台服务器每半个小时使用xtrabackup对mysql做一次增备,

    这个增备的起点是基于每天凌晨5点的全备进行的,也就意味着随着时间增备的数据量会越来越大,

    备份时长也会越来越长,也就意味着系统资源会越来越紧张,以下也可以看到数据的增长情况

    # du -sh *

    2.4G    201602261030

    2.5G    201602261100

    很显然通过以上的分析我们需要做以下三件事情来解决mysql的OOM

    1.将innodb_buffer_pool_size设置为48G

    2.将vm.swappiness设置为1

    3.调整增量备份时间(需要和业务平衡),拉长增量备份的间隔,降低系统的资源消耗

    0b1331709591d260c1c78e86d0c51c18.png

    展开全文
  • 9种OOM问题及解决办法

    2021-06-26 19:58:29
    OOM Killer 会对所有进程进行打分,然后将评分较低的进程“杀死”,具体的评分规则可以参考 Surviving the Linux OOM Killer。 不同于其他的 OOM 错误, Killprocessorsacrifice child 错误不是由 JVM 层面触发的...

    1、Java heap space

    当堆内存(Heap Space)没有足够空间存放新创建的对象时,就会抛出 java.lang.OutOfMemoryError:Javaheap space 错误(根据实际生产经验,可以对程序日志中的 OutOfMemoryError 配置关键字告警,一经发现,立即处理)。

    原因分析

    Javaheap space 错误产生的常见原因可以分为以下几类:

    1、请求创建一个超大对象,通常是一个大数组。

    2、超出预期的访问量/数据量,通常是上游系统请求流量飙升,常见于各类促销/秒杀活动,可以结合业务流量指标排查是否有尖状峰值。

    3、过度使用终结器(Finalizer),该对象没有立即被 GC。

    4、内存泄漏(Memory Leak),大量对象引用没有释放,JVM 无法对其自动回收,常见于使用了 File 等资源没有回收。

    解决方案

    针对大部分情况,通常只需要通过 -Xmx 参数调高 JVM 堆内存空间即可。如果仍然没有解决,可以参考以下情况做进一步处理:

    1、如果是超大对象,可以检查其合理性,比如是否一次性查询了数据库全部结果,而没有做结果数限制。

    2、如果是业务峰值压力,可以考虑添加机器资源,或者做限流降级。

    3、如果是内存泄漏,需要找到持有的对象,修改代码设计,比如关闭没有释放的连接。

    2、GC overhead limit exceeded

    当 Java 进程花费 98% 以上的时间执行 GC,但只恢复了不到 2% 的内存,且该动作连续重复了 5 次,就会抛出 java.lang.OutOfMemoryError:GC overhead limit exceeded 错误。简单地说,就是应用程序已经基本耗尽了所有可用内存, GC 也无法回收。

    此类问题的原因与解决方案跟 Javaheap space 非常类似,可以参考上文。

    3、Permgen space

    该错误表示永久代(Permanent Generation)已用满,通常是因为加载的 class 数目太多或体积太大。

    原因分析

    永久代存储对象主要包括以下几类:

    1、加载/缓存到内存中的 class 定义,包括类的名称,字段,方法和字节码;

    2、常量池;

    3、对象数组/类型数组所关联的 class;

    4、JIT 编译器优化后的 class 信息。

    PermGen 的使用量与加载到内存的 class 的数量/大小正相关。

    解决方案

    根据 Permgen space 报错的时机,可以采用不同的解决方案,如下所示:

    1、程序启动报错,修改 -XX:MaxPermSize 启动参数,调大永久代空间。

    2、应用重新部署时报错,很可能是没有应用没有重启,导致加载了多份 class 信息,只需重启 JVM 即可解决。

    3、运行时报错,应用程序可能会动态创建大量 class,而这些 class 的生命周期很短暂,但是 JVM 默认不会卸载 class,可以设置 -XX:+CMSClassUnloadingEnabled 和 -XX:+UseConcMarkSweepGC这两个参数允许 JVM 卸载 class。

    如果上述方法无法解决,可以通过 jmap 命令 dump 内存对象 jmap-dump:format=b,file=dump.hprof ,然后利用 Eclipse MAT https://www.eclipse.org/mat 功能逐一分析开销最大的 classloader 和重复 class。

    4、Metaspace

    JDK 1.8 使用 Metaspace 替换了永久代(Permanent Generation),该错误表示 Metaspace 已被用满,通常是因为加载的 class 数目太多或体积太大。

    此类问题的原因与解决方法跟 Permgenspace 非常类似,可以参考上文。需要特别注意的是调整 Metaspace 空间大小的启动参数为 -XX:MaxMetaspaceSize

    5、Unable to create new native thread

    每个 Java 线程都需要占用一定的内存空间,当 JVM 向底层操作系统请求创建一个新的 native 线程时,如果没有足够的资源分配就会报此类错误。

    原因分析

    JVM 向 OS 请求创建 native 线程失败,就会抛出 Unableto createnewnativethread,常见的原因包括以下几类:

    1、线程数超过操作系统最大线程数 ulimit 限制;

    2、线程数超过 kernel.pid_max(只能重启);

    3、native 内存不足;

    该问题发生的常见过程主要包括以下几步:

    1、JVM 内部的应用程序请求创建一个新的 Java 线程;

    2、JVM native 方法代理了该次请求,并向操作系统请求创建一个 native 线程;

    3、操作系统尝试创建一个新的 native 线程,并为其分配内存;

    4、如果操作系统的虚拟内存已耗尽,或是受到 32 位进程的地址空间限制,操作系统就会拒绝本次 native 内存分配;

    5、JVM 将抛出 java.lang.OutOfMemoryError:Unableto createnewnativethread 错误。

    解决方案

    1、升级配置,为机器提供更多的内存;

    2、降低 Java Heap Space 大小;

    3、修复应用程序的线程泄漏问题;

    4、限制线程池大小;

    5、使用 -Xss 参数减少线程栈的大小;

    6、调高 OS 层面的线程最大数:执行 ulimia-a 查看最大线程数限制,使用 ulimit-u xxx 调整最大线程数限制。

    ulimit -a .... 省略部分内容 ..... max user processes (-u) 16384

    6、Out of swap space?

    该错误表示所有可用的虚拟内存已被耗尽。虚拟内存(Virtual Memory)由物理内存(Physical Memory)和交换空间(Swap Space)两部分组成。当运行时程序请求的虚拟内存溢出时就会报 Outof swap space? 错误。

    原因分析

    该错误出现的常见原因包括以下几类:

    1、地址空间不足;

    2、物理内存已耗光;

    3、应用程序的本地内存泄漏(native leak),例如不断申请本地内存,却不释放。

    4、执行 jmap-histo:live 命令,强制执行 Full GC;如果几次执行后内存明显下降,则基本确认为 Direct ByteBuffer 问题。

    解决方案

    根据错误原因可以采取如下解决方案:

    1、升级地址空间为 64 bit;

    2、使用 Arthas 检查是否为 Inflater/Deflater 解压缩问题,如果是,则显式调用 end 方法。

    3、Direct ByteBuffer 问题可以通过启动参数 -XX:MaxDirectMemorySize 调低阈值。

    4、升级服务器配置/隔离部署,避免争用。

    7、 Kill process or sacrifice child

    有一种内核作业(Kernel Job)名为 Out of Memory Killer,它会在可用内存极低的情况下“杀死”(kill)某些进程。OOM Killer 会对所有进程进行打分,然后将评分较低的进程“杀死”,具体的评分规则可以参考 Surviving the Linux OOM Killer。

    不同于其他的 OOM 错误, Killprocessorsacrifice child 错误不是由 JVM 层面触发的,而是由操作系统层面触发的。

    原因分析

    默认情况下,Linux 内核允许进程申请的内存总量大于系统可用内存,通过这种“错峰复用”的方式可以更有效的利用系统资源。

    然而,这种方式也会无可避免地带来一定的“超卖”风险。例如某些进程持续占用系统内存,然后导致其他进程没有可用内存。此时,系统将自动激活 OOM Killer,寻找评分低的进程,并将其“杀死”,释放内存资源。

    解决方案

    1、升级服务器配置/隔离部署,避免争用。

    2、OOM Killer 调优。

    8、Requested array size exceeds VM limit

    JVM 限制了数组的最大长度,该错误表示程序请求创建的数组超过最大长度限制。

    JVM 在为数组分配内存前,会检查要分配的数据结构在系统中是否可寻址,通常为 Integer.MAX_VALUE-2

    此类问题比较罕见,通常需要检查代码,确认业务是否需要创建如此大的数组,是否可以拆分为多个块,分批执行。

    9、Direct buffer memory

    Java 允许应用程序通过 Direct ByteBuffer 直接访问堆外内存,许多高性能程序通过 Direct ByteBuffer 结合内存映射文件(Memory Mapped File)实现高速 IO。

    原因分析

    Direct ByteBuffer 的默认大小为 64 MB,一旦使用超出限制,就会抛出 Directbuffer memory 错误。

    解决方案

    1、Java 只能通过 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer,因此,可以通过 Arthas 等在线诊断工具拦截该方法进行排查。

    2、检查是否直接或间接使用了 NIO,如 netty,jetty 等。

    3、通过启动参数 -XX:MaxDirectMemorySize 调整 Direct ByteBuffer 的上限值。

    4、检查 JVM 参数是否有 -XX:+DisableExplicitGC 选项,如果有就去掉,因为该参数会使 System.gc() 失效。

    5、检查堆外内存使用代码,确认是否存在内存泄漏;或者通过反射调用 sun.misc.Cleaner 的 clean() 方法来主动释放被 Direct ByteBuffer 持有的内存空间。

    6、内存容量确实不足,升级配置。

    推荐工具&产品

    JVM 内存分析工具 mat

    1、Eclipse Memory Analyzer

    https://www.eclipse.org/mat

    阿里云 APM 产品,支持 OOM 异常关键字告警

    2、ARMS

    https://help.aliyun.com/document_detail/42966.html?spm=a2c4g.11174283.6.685.d69b668cuztvff

    阿里 Java 在线诊断工具 Arthas(阿尔萨斯)

    3、alibaba Arthas

    https://github.com/alibaba/arth

    展开全文
  • OOM问题排查思路与常用指令

    千次阅读 2021-01-17 15:18:15
    OOM问题排查思路与指令 实际生产项目中,不可避免的会遇到服务器内存不足引发告警的问题,很多时候可能就是因为部署的服务占用了太多的内存导致的。 当然,我们可以通过设置java的内存参数来控制内存的最大占用...
  • JAVA OOM问题排查记录

    千次阅读 2021-06-15 17:06:37
    JAVA OOM问题排查记录 问题描述 实际开发中有个定时任务的应用,运行一段时间后就会OOM,通过jvm的各种监控来排查OOM的原因,特此记录在这里。 内容引用 JVM 调优-给你的java应用看看病 Java程序内存分析:使用mat...
  • OOM和内存优化总结 什么是OOM? OOM 即 (java.lang.OutOfMemoryError), JVM没有足够内存给对象分配空间,超过jvm的堆空间最大值(-Xmx参数),此异常就会被触发,导致应用强制被杀死。
  • 转自:...例如:Java.lang.OutOfMemoryError:Javaheapspace【分析】此OOM是由于JVM中heap的最大值不满足需要,将设置heap的最大值调高即可,参数样例为:-Xmx2G【解决方法】调高hea...
  • 定位一个oom问题

    2021-02-01 10:49:51
    当系统出现oom问题时,我们一般的定位思路是怎样的? 系统OOM常见的原因有: 1、用户态内存需求过多,资源不足; 2、大页配置不正确; 3、水位线值异常; 4、slab内存过多; 5、rcu异常; OOM问题定位步骤如下: 1、...
  • $ top #或ps $ pmap 上面3步可以用工具bcc包中的memleak分析 $ memleak -a -p $(pidof app) #已知进程号情况下,或者直接 $memleak -a 2、内存泄露最终通过OOM释放 #查看OOM的进程 $ grep "Out of memory" /var/log/...
  • 线上OOM问题排查

    万次阅读 2021-06-26 14:59:32
    java -Xms48m -Xmx48m -XX:+HeapDumpOnOutOfMemoryError XX:HeapDumpPath=./heapdump.prof -jar 使用jprofiler 查看dump文件 与及 call tree 分析
  • 本文来说下JVM性能优化之OOM问题 文章目录概述 概述
  • 问题描述用户问题:用户发现自己的服务器CPU在某一时刻陡然升高,但从监控上看,同一时刻的业务量却并不高,客户怀疑是云服务器有问题,希望技术支持团队予以解决。经过我们的排查,发现cpu的两次间歇飙高是由于客户...
  • 解决方案 争对大多数的内存溢出的情况,只需要调整jvm的堆内存空间就可以解决该问题,如果还没有解决可以根据以下几种情况进行排查 如果是超大对象,可以检查其合理性,比如是否一次性查询了数据库全部结果,而没有...
  • 说实话之前之前没怎么接触过POI组件,只知道有这么一个东西可以解决excel读写问题,但不用不知道,使用起来真心无语,到处都是坑。接下来我讲分享一些在项目中遇到的坑及解决方法,其实社区也有不少类似文章,但讲的...
  • java OOM问题分析排查

    2020-12-23 14:33:24
    java服务OOM最常见的原因: 内存分配过小,而正常业务需要使用更大的内存; 某一个对象被频繁申请,确没有释放,内存不断泄露,导致内存耗尽; 某一个资源被不断申请,系统资源耗尽,如:不断创建线程,不断发起...
  • 生产出现oom问题,怎么排查?
  • 某Java服务(假设PID=10765)出现了OOM,最常见的原因为: 有可能是内存分配确实过小,而正常业务使用了大量内存 某一个对象被频繁申请,却没有释放,内存不断泄漏,导致内存耗尽 某一个资源被频繁申请,系统资源...
  • 2.问题介绍 代码写完。运行后。发现没过多久项目就报错。java.lang.OutOfMemoryError: unable to create new native thread 3.问题排查 使用工具jvisualvm进行排查 从上图可以看到问题有哪些? a.cpu占用...
  • 最近项目上在测试人员压测过程中发现了OOM问题,项目使用springboot搭建项目工程,通过查看日志中包含信息:unable to create new native thread内存溢出的三种类型:1.第一种OutOfMemoryError: PermGen space,...
  • 实操--OOM问题 OOM-内存 OOM: out of memory 关于JVM的内存相关的配置很多开源的JAVA组件上有对应的推荐 eg:http://rocketmq.apache.org/docs/system-config/ 1. 内存分配 线上jvm-没有太多样 > jvm堆内存占70%...
  • 代码中使用RestTemplate下载大文件,发现会OOM,代码如下: RestTemplate restTemplate = new RestTemplate(); // 会OOM ResponseEntity<byte[]> entity = restTemplate.getForEntity(...
  • 今天早上09:30-09:40时分,presto集群又出现了多个worker节点OOM然后服务挂掉的问题。集群此时非常的不稳定。 看来了下节点的日志,是发生了内存堆溢出 java.lang.OutOfMemoryError: Java heap space Dumping heap ...
  • 问题复现工作中,项目里的导入功能采用了poi读取然后进行业务操作,在导入50M文件时发生了OOM报错信息,以下是本地复现的错误信息(由于环境不一样,本地导入14M的文件就已出现错误) 究其原因项目中使用WorkBook这个...
  • jvm oom 问题排查

    2021-02-18 11:47:41
    0、样例代码: public class HeapOOM { public static void main...5、flink几个oom的例子 JAVA各种OOM代码样例及解决方法 - 黄青石 - 博客园 6、jvm导致cpu过高原因排查 1、cpu空转 2、一般是大集合处理或死循环导致。
  • 今天面试支付宝,其实没有一点把握,就是想看看自己这段时间的学习有没有成果,还有什么不足的地方,面试的时候问了一个比较常见的问题就是oom问题,但是自己平时没有对这块知识的积累,后来上网查阅资料发现其实这...
  • $ top #或ps $ pmap 上面3步可以用工具bcc包中的memleak分析 $ memleak -a -p $(pidof app) #已知进程号情况下,或者直接 $memleak -a 2、内存泄露最终通过OOM释放 #查看OOM的进程 $ grep "Out of memory" /var/log/...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 127,105
精华内容 50,842
关键字:

oom问题