Kubernetes 中 JVM 故障问题排查心得总结

在我们日常的工作当中，通常应用都会采用Kubernetes进行容器化部署，但是总是会出现一些问题，例如，JVM堆小于Docker容器中设置的内存大小和Kubernetes的内存大小，但是还是会被OOMKilled。在此我们介绍一下K8s的OOMKilled的Exit Code编码。

▍Exit Code 137

表明容器收到了 SIGKILL 信号，进程被杀掉，对应kill -9，引发SIGKILL的是docker kill。这可以由用户或由docker守护程序来发起，手动执行：docker kill
▎137比较常见，如果 pod 中的limit 资源设置较小，会运行内存不足导致 OOMKilled，此时state 中的 ”OOMKilled” 值为true，你可以在系统的dmesg -T 中看到OOM日志。

▍为什么我设置的大小关系没有错，还会OOMKilled？

因为我的heap大小肯定是小于Docker容器以及Pod的大小的，为啥还是会出现OOMKilled？

原因分析

这种问题常发生在JDK8u131或者JDK9版本之后所出现在容器中运行JVM的问题：在大多数情况下，JVM将一般默认会采用宿主机Node节点的内存为Native VM空间（其中包含了堆空间、直接内存空间以及栈空间），而并非是是容器的空间为标准。

例如在我的机器

docker run -m 100MB openjdk:8u121 java -XshowSettings:vm -version
VM settings:
    Max. Heap Size (Estimated): 444.50M
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

以上的信息出现了矛盾，我们在运行的时候将容器内存设置为100MB，而-XshowSettings:vm打印出的JVM将最大堆大小为444M，如果按照这个内存进行分配内存的话很可能会导致节点主机在某个时候杀死我的JVM。

如何解决此问题

JVM 感知 cgroup 限制

一种方法解决 JVM 内存超限的问题，这种方法可以让JVM自动感知 docker 容器的 cgroup 限制，从而动态的调整堆内存大小。JDK8u131在JDK9中有一个很好的特性，即JVM能够检测在Docker容器中运行时有多少内存可用。为了使jvm保留根据容器规范的内存，必须设置标志-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap。

注意：如果将这两个标志与Xms和Xmx标志一起设置，那么jvm的行为将是什么？-Xmx标志将覆盖-XX:+ UseCGroupMemoryLimitForHeap标志。

总结一下

标志-XX:+ UseCGroupMemoryLimitForHeap使JVM可以检测容器中的最大堆大小。
-Xmx标志将最大堆大小设置为固定大小。
除了JVM的堆空间，还会对于非堆和jvm的东西，还会有一些额外的内存使用情况。

使用JDK9的容器感知机制尝试

$ docker run -m 100MB openjdk:8u131 java 
  -XX:+UnlockExperimentalVMOptions 
  -XX:+UseCGroupMemoryLimitForHeap 
  -XshowSettings:vm -version
VM settings:
    Max. Heap Size (Estimated): 44.50M
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

可以看出来通过内存感知之后，JVM能够检测到容器只有100MB，并将最大堆设置为44M。我们调整一下内存大小看看是否可以实现动态化调整和感知内存分配，如下所示。

docker run -m 1GB openjdk:8u131 java 
  -XX:+UnlockExperimentalVMOptions 
  -XX:+UseCGroupMemoryLimitForHeap 
  -XshowSettings:vm -version
VM settings:
    Max. Heap Size (Estimated): 228.00M
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

我们设置了容器有1GB内存分配，而JVM使用228M作为最大堆。因为容器中除了JVM之外没有其他进程在运行，所以我们还可以进一步扩大一下对于Heap堆的分配？

$ docker run -m 1GB openjdk:8u131 java 
  -XX:+UnlockExperimentalVMOptions 
  -XX:+UseCGroupMemoryLimitForHeap 
  -XX:MaxRAMFraction=1 -XshowSettings:vm -version
VM settings:
    Max. Heap Size (Estimated): 910.50M
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

在较低的版本的时候可以使用-XX:MaxRAMFraction参数，它告诉JVM使用可用内存/MaxRAMFract作为最大堆。使用-XX:MaxRAMFraction=1，我们将几乎所有可用内存用作最大堆。从上面的结果可以看出来内存分配已经可以达到了910.50M。

问题分析

最大堆占用总内存是否仍然会导致你的进程因为内存的其他部分（如“元空间”）而被杀死？

答案：MaxRAMFraction=1仍将为其他非堆内存留出一些空间

但如果容器使用堆外内存，这可能会有风险，因为几乎所有的容器内存都分配给了堆。您必须将-XX:MaxRAMFraction=2设置为堆只使用50%的容器内存，或者使用Xmx。

容器内部感知CGroup资源限制

Docker1.7开始将容器cgroup信息挂载到容器中，所以应用可以从 /sys/fs/cgroup/memory/memory.limit_in_bytes 等文件获取内存、 CPU等设置，在容器的应用启动命令中根据Cgroup配置正确的资源设置 -Xmx, -XX:ParallelGCThreads等参数

在Java10中，改进了容器集成：

Java10+废除了-XX:MaxRAM参数，因为JVM将正确检测该值。在Java10中，改进了容器集成。无需添加额外的标志，JVM将使用1/4的容器内存用于堆。
java10+确实正确地识别了内存的docker限制，但您可以使用新的标志MaxRAMPercentage（例如：-XX:MaxRAMPercentage=75）而不是旧的MaxRAMFraction，以便更精确地调整堆的大小，而不是其余的（堆栈、本机…）
java10+上的UseContainerSupport选项，而且是默认启用的，不用设置。同时 UseCGroupMemoryLimitForHeap 这个就弃用了，不建议继续使用，同时还可以通过 -XX:InitialRAMPercentage、-XX:MaxRAMPercentage、-XX:MinRAMPercentage 这些参数更加细腻的控制 JVM 使用的内存比率。

Java 程序在运行时会调用外部进程、申请 Native Memory 等，所以即使是在容器中运行 Java 程序，也得预留一些内存给系统的。所以 -XX:MaxRAMPercentage 不能配置得太大。当然仍然可以使用-XX:MaxRAMFraction=1选项来压缩容器中的所有内存。

上面我们知道了如何进行设置和控制对应的堆内存和容器内存的之间的关系，所以防止JVM的堆内存超过了容器内存，导致容器出现OOMKilled的情况。但是在整个JVM进程体系而言，不仅仅只包含了Heap堆内存，其实还有其他相关的内存存储空间是需要我们考虑的，一边防止这些内存空间会造成我们的容器内存溢出的场景，正如下图所示。

Java 内存模型& COM错误

接下来了我们需要进行分析出heap之外的一部分就是对外内存就是Off Heap Space，也就是Direct buffer memory堆外内存。主要通过的方式就是采用Unsafe方式进行申请内存，大多数场景也会通过Direct ByteBuffer方式进行获取。好废话不多说进入正题。

▍JVM参数MaxDirectMemorySize

我们先研究一下jvm的-XX:MaxDirectMemorySize，该参数指定了DirectByteBuffer能分配的空间的限额，如果没有显示指定这个参数启动jvm，默认值是xmx对应的值（低版本是减去幸存区的大小）。

DirectByteBuffer对象是一种典型的”冰山对象”，在堆中存在少量的泄露的对象，但其下面连接用堆外内存，这种情况容易造成内存的大量使用而得不到释放

-XX:MaxDirectMemorySize

-XX:MaxDirectMemorySize=size 用于设置 New I/O (java.nio) direct-buffer allocations 的最大大小，size 的单位可以使用 k/K、m/M、g/G；如果没有设置该参数则默认值为 0，意味着JVM自己自动给NIO direct-buffer allocations选择最大大小。

-XX:MaxDirectMemorySize的默认值是什么？

在sun.misc.VM中，它是Runtime.getRuntime.maxMemory()，这就是使用-Xmx配置的内容。而对应的JVM参数如何传递给JVM底层的呢？主要通过的是hotspot/share/prims/jvm.cpp。我们来看一下jvm.cpp的JVM源码来分一下。

  // Convert the -XX:MaxDirectMemorySize= command line flag
  // to the sun.nio.MaxDirectMemorySize property.
  // Do this after setting user properties to prevent people
  // from setting the value with a -D option, as requested.
  // Leave empty if not supplied
  if (!FLAG_IS_DEFAULT(MaxDirectMemorySize)) {
    char as_chars[256];
    jio_snprintf(as_chars, sizeof(as_chars), JULONG_FORMAT, MaxDirectMemorySize);
    Handle key_str = java_lang_String::create_from_platform_dependent_str("sun.nio.MaxDirectMemorySize", CHECK_NULL);
    Handle value_str  = java_lang_String::create_from_platform_dependent_str(as_chars, CHECK_NULL);
    result_h->obj_at_put(ndx * 2,  key_str());
    result_h->obj_at_put(ndx * 2 + 1, value_str());
    ndx++;
  }

jvm.cpp 里头有一段代码用于把 – XX:MaxDirectMemorySize 命令参数转换为 key 为 sun.nio.MaxDirectMemorySize的属性。我们可以看出来他转换为了该属性之后，进行设置和初始化直接内存的配置。针对于直接内存的核心类就在

public class VM {

    // the init level when the VM is fully initialized
    private static final int JAVA_LANG_SYSTEM_INITED     = 1;
    private static final int MODULE_SYSTEM_INITED        = 2;
    private static final int SYSTEM_LOADER_INITIALIZING  = 3;
    private static final int SYSTEM_BOOTED               = 4;
    private static final int SYSTEM_SHUTDOWN             = 5;


    // 0, 1, 2, ...
    private static volatile int initLevel;
    private static final Object lock = new Object();

    //......

    // A user-settable upper limit on the maximum amount of allocatable direct
    // buffer memory.  This value may be changed during VM initialization if
    // "java" is launched with "-XX:MaxDirectMemorySize=".
    //
    // The initial value of this field is arbitrary; during JRE initialization
    // it will be reset to the value specified on the command line, if any,
    // otherwise to Runtime.getRuntime().maxMemory().
    //
    private static long directMemory = 64 * 1024 * 1024;

上面可以看出来64MB最初是任意设置的。在-XX:MaxDirectMemorySize 是用来配置NIO direct memory上限用的VM参数。可以看一下JVM的这行代码。

product(intx, MaxDirectMemorySize, -1,
        "Maximum total size of NIO direct-buffer allocations")

但如果不配置它的话，direct memory默认最多能申请多少内存呢？这个参数默认值是-1，显然不是一个“有效值”。所以真正的默认值肯定是从别的地方来的。

    // Returns the maximum amount of allocatable direct buffer memory.
    // The directMemory variable is initialized during system initialization
    // in the saveAndRemoveProperties method.
    //
    public static long maxDirectMemory() {
        return directMemory;
    }

    //......

    // Save a private copy of the system properties and remove
    // the system properties that are not intended for public access.
    //
    // This method can only be invoked during system initialization.
    public static void saveProperties(Map props) {
        if (initLevel() != 0)
            throw new IllegalStateException("Wrong init level");

        // only main thread is running at this time, so savedProps and
        // its content will be correctly published to threads started later
        if (savedProps == null) {
            savedProps = props;
        }

        // Set the maximum amount of direct memory.  This value is controlled
        // by the vm option -XX:MaxDirectMemorySize=.
        // The maximum amount of allocatable direct buffer memory (in bytes)
        // from the system property sun.nio.MaxDirectMemorySize set by the VM.
        // If not set or set to -1, the max memory will be used
        // The system property will be removed.
        String s = props.get("sun.nio.MaxDirectMemorySize");
        if (s == null || s.isEmpty() || s.equals("-1")) {
            // -XX:MaxDirectMemorySize not given, take default
            directMemory = Runtime.getRuntime().maxMemory();
        } else {
            long l = Long.parseLong(s);
            if (l > -1)
                directMemory = l;
        }
        // Check if direct buffers should be page aligned
        s = props.get("sun.nio.PageAlignDirectMemory");
        if ("true".equals(s))
            pageAlignDirectMemory = true;
    }
    //......
}

从上面的源码可以读取 sun.nio.MaxDirectMemorySize 属性，如果为 null 或者是空或者是 – 1，那么则设置为 Runtime.getRuntime ().maxMemory ()；如果有设置 MaxDirectMemorySize 且值大于 – 1，那么使用该值作为 directMemory 的值；而 VM 的 maxDirectMemory 方法则返回的是 directMemory 的值。

因为当MaxDirectMemorySize参数没被显式设置时它的值就是-1，在Java类库初始化时maxDirectMemory()被java.lang.System的静态构造器调用，走的路径就是这条：

if (s.equals("-1")) {  
    // -XX:MaxDirectMemorySize not given, take default  
    directMemory = Runtime.getRuntime().maxMemory();  
}

而Runtime.maxMemory()在HotSpot VM里的实现是：

JVM_ENTRY_NO_ENV(jlong, JVM_MaxMemory(void))  
  JVMWrapper("JVM_MaxMemory");  
  size_t n = Universe::heap()->max_capacity();  
  return convert_size_t_to_jlong(n);  
JVM_END

这个max_capacity()实际返回的是 -Xmx减去一个survivor space的预留大小。

结论分析说明

MaxDirectMemorySize没显式配置的时候，NIO direct memory可申请的空间的上限就是-Xmx减去一个survivor space的预留大小。例如如果您不配置-XX:MaxDirectMemorySize并配置-Xmx5g，则”默认” MaxDirectMemorySize也将是5GB-survivor space区，并且应用程序的总堆+直接内存使用量可能会增长到5 + 5 = 10 Gb 。

其他获取 maxDirectMemory 的值的API方法

BufferPoolMXBean 及 JavaNioAccess.BufferPool (通过SharedSecrets获取) 的 getMemoryUsed 可以获取 direct memory 的大小；其中 java9 模块化之后，SharedSecrets 从原来的 sun.misc.SharedSecrets 变更到 java.base 模块下的 jdk.internal.access.SharedSecrets；要使用 –add-exports java.base/jdk.internal.access=ALL-UNNAMED 将其导出到 UNNAMED，这样才可以运行。

public BufferPoolMXBean getDirectBufferPoolMBean(){
        return ManagementFactory.getPlatformMXBeans(BufferPoolMXBean.class)
                .stream()
                .filter(e -> e.getName().equals("direct"))
                .findFirst()
                .orElseThrow();
}
public JavaNioAccess.BufferPool getNioBufferPool(){
     return SharedSecrets.getJavaNioAccess().getDirectBufferPool();
}

内存分析问题

-XX:+DisableExplicitGC 与 NIO的direct memory

用了-XX:+DisableExplicitGC参数后，System.gc()的调用就会变成一个空调用，完全不会触发任何GC（但是“函数调用”本身的开销还是存在的哦～）。
做ygc的时候会将新生代里的不可达的DirectByteBuffer对象及其堆外内存回收了，但是无法对old里的DirectByteBuffer对象及其堆外内存进行回收，这也是我们通常碰到的最大的问题，如果有大量的DirectByteBuffer对象移到了old，但是又一直没有做cms gc或者full gc，而只进行ygc，那么我们的物理内存可能被慢慢耗光，但是我们还不知道发生了什么，因为heap明明剩余的内存还很多(前提是我们禁用了System.gc)。

阅读原文：https://juejin.cn/post/7171444889300205598

Kubernetes 中 JVM 故障问题排查心得总结