JVM感知docker容器内存资源限制

容器中的java程序无法感知docker的内存资源限制
[root@xm-phy-kvm-113-2 ~]# docker run -m 100MB openjdk:8u131 java -XshowSettings:vm -version
VM settings:
    Max. Heap Size (Estimated): 17.43G
    Ergonomics Machine Class: server
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

 我设置了 100MB 的容器内存,但JVM 设置了17.3G 的最大堆?它很可能会导致内核在某个时候杀死JVM程序

[root@xm-phy-kvm-113-2 ~]# 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

openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
java服务无感知docker资源限制导致的问题

在K8s中Deployments配置资源限制和预留的时候,比如设置最大内存为100M。但是宿主机的总内存为80G,这时候Pod启动后会超出内存限制,被Deployments杀掉。但为了维护设置的副本数量又创建新的,如此反复。

原因是默认情况JVM默认最大堆空间为系统总内存的1/4,在容器中没有感知到集群为Pod设置的资源限制,而是按宿主机的内存算的,所以最终超过限制内存。

解决方案

解决思路有两种:

  • 按资源限制算好,在 Java 启动参数中设置堆内存大小,保证不超限制
  • 让JVM感知到容器资源限制,按这个值来分配内存

Java SE 8u131向后 和 JDK 9 都有参数支持:如下

-XX:+UnlockExperimentalVMOptions 
-XX:+UseCGroupMemoryLimitForHeap

但是如果资源限制默认分配1/4有点浪费,因为一般一个Pod就跑这一个主要进程,所以可以改下这个默认值,如下:

# 2 代表1/2
-XX:MaxRAMFraction=2

这样配置并不代表就是资源限制的1/2,因为除了堆内存还有其他堆外内存需要空间,所以实际值要远小于1/2。网上有人在测试环境设置1,代表100%,但是我试过之后还是超过资源限制了,所以选了2,实际需要根据情况决定。

Java 8u131及以上版本开始支持了Docker的cpu和memory限制。

cpu limit(默认支持)

即如果没有显式指定-XX:ParalllelGCThreads 或者 -XX:CICompilerCount, 那么JVM使用docker的cpu限制。如果docker有指定cpu limit,jvm参数也有指定-XX:ParalllelGCThreads 或者 -XX:CICompilerCount,那么以指定的参数为准。

memory limit

在java8u131+及java9,需要加上-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap才能使得Xmx感知docker的memory limit。

参数/版本-XX:+UseCGroupMemoryLimitForHeap-XX:ActiveProcessorCount-XX:+UseContainerSupport
java9experimental,默认false
java10experimental,默认false-1
java11移除-1product,默认true

参考链接:
链接:
https://segmentfault.com/a/1190000014142950

Java SE support for Docker CPU and memory limits

Running a JVM in a Container Without Getting Killed

让JVM感知K8s资源限制 - 简书

  • 12
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
监控Kubernetes(K8s)容器内部的JVM是一种重要的操作,它能够帮助我们了解JVM的性能和健康状况以及整个容器环境中JVM的运行情况。以下是一些方法和工具来监控K8s容器内部的JVM。 首先,我们可以使用Kubernetes Dashboard或类似的监控工具来查看容器资源使用情况,例如CPU、内存和存储。这可以帮助我们了解JVM是否正在消耗太多的资源或者是否需要进行资源调整。 其次,我们可以通过日志收集工具,如ELK(Elasticsearch、Logstash和Kibana)堆栈,监控JVM的日志输出。这些工具可以帮助我们实时查看JVM的日志,并进行搜索和过滤。 另外,可以使用性能监控工具,例如Prometheus和Grafana,来监控JVM的性能指标,如内存使用、GC(垃圾回收)时间、线程和类加载情况等。这些工具提供了仪表板和可视化图表,使我们能够直观地了解JVM的运行情况。 还可以使用工具如VisualVM和JMX(Java Management Extensions)来远程监控JVM。这些工具可以通过JMX协议访问JVM的MBean(管理Bean),并提供可视化界面来监控和分析JVM的运行时数据。 最后,我们还可以使用APM(Application Performance Monitoring)工具来监控K8s容器内部的JVM。APM工具可以提供更深入的性能监控和分析,例如方法级别的调用链跟踪、错误和异常的监测等。 综上所述,监控K8s容器内部的JVM可以通过使用Kubernetes Dashboard、ELK堆栈、Prometheus和Grafana、VisualVM、JMX和APM等工具来实现。这可以帮助我们全面了解JVM的性能和健康状况,并及时发现和解决潜在的问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值