JVM参数之MaxDirectMemorySize

1、Java_JVM参数-XX:MaxDirectMemorySize 与 两种 ByteBuffer: heap,direct ByteBuffer(参考:https://www.cnblogs.com/laoqing/p/10380536.html)

     ByteBuffer有两种:
     heap ByteBuffer -> -XX:Xmx
     1.1、一种是heap ByteBuffer,该类对象分配在JVM的堆内存里面,直接由Java虚拟机负责垃圾回收;

     direct ByteBuffer -> -XX:MaxDirectMemorySize
     1.2、一种是direct ByteBuffer是通过jni在虚拟机外内存中分配的。通过jmap无法查看该快内存的使用情况。只能通过top来看它的内存使用情况。
           1.2.1、JVM堆内存大小可以通过-Xmx来设置,同样的direct ByteBuffer可以通过-XX:MaxDirectMemorySize来设置,此参数的含义是当Direct ByteBuffer分配的堆外内存到达指定大小后,即触发Full GC。注意该值是有上限的,默认是64M,最大为sun.misc.VM.maxDirectMemory(),在程序中中可以获得-XX:MaxDirectMemorySize的设置的值。
           1.2.2、没有配置MaxDirectMemorySize的,因此MaxDirectMemorySize的大小即等于-Xmx
           1.2.3、Direct Memory的回收机制,Direct Memory是受GC控制的
           1.2.4、对于使用Direct Memory较多的场景,需要注意下MaxDirectMemorySize的设置,避免-Xmx + Direct Memory超出物理内存大小的现象

2、用JDK8的一定要配置:-Xms -Xmx -XX:MaxDirectMemorySize,【Xmx +(加) MaxDirectMemorySize】的值不能超过docker的最大内存,不然docker内存占满了会被oomkill掉;

     没配置参数导致的问题以及处理参考:http://hellojava.info/?tag=maxdirectmemorysize (物理内存耗尽、CMS GC碎片造成RT慢的两个Case
    分析:https://my.oschina.net/go4it/blog/3029481

3、dmesg排查消失的进程:
      3.1、适用场景:

              如果发现自己的java进程悄无声息的消失了,几乎没有留下任何线索,那么dmesg一发,很有可能有你想要的。

      3.2、具体操作
              sudo dmesg|grep -i kill | less 或者 dmesg | grep kill

      去找关键字oom_killer,找到的结果类似如下:
      [6710782.021013] java invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0, oom_scoe_adj=0 
      [6710782.070639] [] ? oom_kill_process+0x68/0x140 
      [6710782.257588] Task in /LXC011175068174 killed as a result of limit of /LXC011175068174 
      [6710784.698347] Memory cgroup out of memory: Kill process 215701 (java) score 854 or sacrifice child 
      [6710784.707978] Killed process 215701, UID 679, (java) total-vm:11017300kB, anon-rss:7152432kB, file-rss:1232kB

       以上表明,对应的java进程被系统的OOM Killer给干掉了,得分为854. 
       解释一下OOM killer(Out-Of-Memory killer),该机制会监控机器的内存资源消耗。当机器内存耗尽前,该机制会扫描所有的进程(按照一定规则计算,内存占用,时间等),挑选出得分最高的进程,然后杀死,从而保护机器。

 

       dmesg日志时间转换公式: 
       log实际时间=格林威治1970-01-01+(当前时间秒数-系统启动至今的秒数+dmesg打印的log时间)秒数:
       date -d “1970-01-01 UTC echo "$(date +%s)-$(cat /proc/uptime|cut -f 1 -d' ')+12288812.926194"|bc seconds”
       剩下的,就是看看为什么内存这么大,触发了OOM-Killer了。

4、默认情况下,VM将用于直接字节缓冲区的堆内存量限制为最大堆大小的大约85%

 http://lovestblog.cn/blog/2015/05/12/direct-buffer/

 

附:几种内存溢出处理办法:cnblogs.com/leasonWang/p/11146030.html

原文地址:https://www.cnblogs.com/dengq/p/13687423.html