java - JCMD 的代码/内部部分包含什么？

Question

为基于 JVM 的服务确定 docker 容器的尺寸是很棘手的(众所周知)。我很确定我们的容器尺寸略微不足，并且想澄清一些与我们在监控时看到的特定 jcmd( native 内存跟踪器)输出有关的问题。

问题:

• 直接字节缓冲区是否包含在 jcmd 报告的“内部”中？
• jcmd 报告的“代码”中除了代码缓存之外还有什么？
• 是否有一种好方法来限制 jcmd 报告的“代码”部分。我读了https://docs.oracle.com/javase/8/embedded/develop-apps-platforms/codecache.htm但这仅涵盖代码缓存限制，建议保留 JVM 默认值。

JCMD output在这里。

Direct Byte Buffers JMX 属性在这里。

一些背景细节:

设置:

• 基于 Spring Boot 的应用

• JVM 选项:

  -server -Xms1792m -Xmx1792m -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=192M -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MaxDirectMemorySize=256m -XX:NativeMemoryTracking=detail

• 在 AWS/EC2 中运行的 Docker 容器 2500MiB

Answer 1

Are Direct Byte Buffers included in "Internal" as reported by jcmd?

(更新)ByteBuffer.allocateDirect 在内部调用 Unsafe.allocateMemory，is counted由 NMT 在内部部分(由 mtInternal 常量表示)。

相反，MappedByteBuffers(通过 FileChannel.map 获得)没有反射(reflect)在 NMT 报告中，尽管从操作系统的角度来看它们肯定会影响进程使用的内存量。

What else apart from code cache is in "Code" as reported by jcmd?

用于维护已编译代码和生成的运行时 stub 的辅助 VM 结构:哈希表、代码字符串、适配器指纹等。与 CodeCache 本身相比，它们都相当小。这些结构构成报告中的“malloc”部分，而 CodeCache 则进入“mmap”部分。

Is there a good way to limit the "Code" section as reported by jcmd.

关闭分层编译(-XX:-TieredCompilation)很可能会减少“代码”使用的内存量，只是因为生成的代码会少很多。但是请确保您了解什么是分层编译以及它可能对性能产生什么影响。